Should You Charge for a Discovery Phase? (When and How)

Should you charge for a discovery phase? Yes, when you can't write an honest quote without doing real work first: interviews, audits, content inventories, integration checks. No, when the job is simple and one good call gives you everything you need. If you do charge, sell it as a small fixed-price project with named deliverables, and treat what it produces as the scope every later request is judged against.

That last part is the one most people skip. Paid discovery isn't just getting paid for thinking. It gives you a written baseline, which makes every later "can we also..." much easier to sort.

Should you charge for a discovery phase on every project?

No. Charge for a discovery phase when the project has real unknowns that need research to price, such as integrations, migrations, several stakeholder groups or content nobody has counted yet. For a small, well-defined job you could quote from one call, fold the planning into the price. Charging for discovery there just bills the client for your sales process.

A useful way to think about it: the sales call is free, the written plan isn't. Be generous on the call. Ask good questions, share your first thoughts, tell them what you'd look at. Then, if the honest answer to "what will this cost?" is "I don't know yet, and neither do you," that gap is the paid work.

Here's a quick test. After the first call, try writing the scope of work. If you can fill in the page count, the features, the integrations and who supplies content without guessing, you probably don't need paid discovery. If half the lines say "TBC," you do. Our scope of work template is a good way to run that test, because the blanks show up fast.

What is a discovery phase?

A discovery phase is the research and planning stage before you design or build anything. You learn who the users are, what the client actually needs, what constraints exist (tech, content, budget, deadlines) and what success looks like. The output is a written plan and a scope you can price, not a design or working code.

The UK government's Service Manual on how the discovery phase works is written for public services, not agency websites, but several of its points carry over well:

• Before you commit to building something, you need to understand the problem it solves.

• You shouldn't start building during discovery.

• If the client arrives with a ready-made solution ("we need an interactive map"), reframe it as a problem first, and agree what isn't part of the problem.

• Discovery is finished when you can decide whether to go ahead, and stopping there isn't a failure if that's what the research shows.

That third point matters most for agencies. "We need a booking system" might really mean "fewer phone calls about availability," and those can be very different builds.

What's the difference between discovery and a proposal?

A proposal is your free pitch: what you'd do, roughly what it costs, why you. Discovery is paid work that produces the facts the final quote is built on. A rough proposal can come before discovery, with a range and a note that the firm price follows discovery. The detailed, fixed quote comes after it.

When should you skip paid discovery?

Skip paid discovery when the work is routine, when you've done nearly the same project for this client before, or when the scope is narrow enough that a solid brief and one scoping call cover the same ground. In those cases, spend an hour or two on planning, include it in your price, and say so in the quote.

Also skip it if the client hasn't got budget sign-off for a build yet; a free call that ends with a ballpark range is the better move. What you shouldn't do is skip discovery and then quote a fixed price on a guess. Write your assumptions down instead (more on that below).

What should a paid discovery phase include?

A paid discovery phase should include deliverables the client can hold: a project brief (goals, audiences, success measures), a sitemap and content plan, technical and integration requirements, what's in and out of scope, assumptions and risks, and a priced build quote. The client should own the document whether they hire you or not.

Here's a practical set of discovery phase deliverables for a web project. A small job might only need four of them.

1. Project brief. Business goals, who the site is for, what they need to do on it, and how you'll know it worked.

2. Sitemap and page list. Every page or template, counted. "About 10 pages" isn't a page list.

3. Content plan. Which pages exist, which get rewritten, who writes them, who approves them, and by when.

4. Technical requirements. CMS, hosting, forms, analytics, and every integration with what it has to do.

5. Migration and SEO notes, if there's an existing site: which URLs matter, what needs redirects.

6. In scope and out of scope. The inclusions and the exclusions, both written as plainly as each other.

7. Assumptions and risks. "Client supplies all product photos." "Booking provider has a usable API." Each one is a thing that changes the price if it turns out to be wrong.

8. Phasing. What's in version one and what waits for later.

9. The build quote. Price, timeline and revision rounds for the next phase, based on everything above.

The APM's page on what scope management is makes the point behind items 6 and 7 directly: clearly defining what's in and out of scope prevents misunderstandings later in a project that lead to change requests, and assumptions get documented during scoping to clarify what's part of the work. That's what you're really selling: fewer arguments in month two.

What does a website discovery process look like?

A typical website discovery process: a kickoff call with the decision-maker, short interviews with people who'll use or edit the site, a review of the current site and analytics, a content and page inventory, an integration check, then a written plan and a priced quote. You present it, take one round of questions, and the client decides.

Give the discovery its own scope, too: how many interviews, how many review rounds on the document, and a delivery date. A discovery that keeps growing is just unpaid scope creep with a nicer name.

How do you price a discovery phase?

Price a discovery phase as a fixed fee built from your own time estimate: count the calls, interviews, audits and writing hours, multiply by your rate, and add some room for one round of questions on the final document. Take payment before you start. Don't base the fee on a percentage of a build nobody has scoped yet.

You'll see percentage rules of thumb online. A share of an unknown number is still a guess, and replacing the guess is the point of discovery. Build it from hours.

There are three common ways to bill it:

Fixed fee is the default for most small studios. It's easy to approve, and it forces you to define the deliverables. Don't price it low to win the relationship, either. If the fee feels too high for the client, shrink the deliverables, not your rate.

Should the discovery fee be credited toward the project?

You can, but you don't have to. Some agencies credit all or part of the fee if the client signs the build by a set date. Others don't, because the discovery document is a finished deliverable the client can take anywhere. What matters is that the discovery agreement says which one applies, and the deadline if there's a credit.

A time-limited credit is a fair middle ground: it rewards a quick decision without leaving an open-ended discount on the table.

How long should a discovery phase take?

It depends on the project, so scope it by deliverables, not by a standard number of weeks. A small website discovery might be a handful of calls and a few days of writing. A complex build with integrations or a migration can take several weeks. Set a delivery date for the discovery document in the agreement so it doesn't drift.

The GOV.UK guidance says there's no set length and that around four to eight weeks is typical for government services, which involve far more teams and research than most agency web projects. Its rule fits any size, though: let the goal of the discovery decide how long it takes.

In practice, the client's calendar is what slows it down. Put their responsibilities in the agreement (who you need to talk to, by when), the same way you would for content on a build.

How do you pitch paid discovery to a client?

Pitch paid discovery as risk reduction, not as an upsell. Tell the client what you don't know yet, why guessing would mean padding the quote or fighting about scope later, and what they'll get: a written plan and a firm price they own either way. Give one fixed fee, one delivery date and a clear next step.

Be specific. "There are unknowns" sounds like a sales line. "I don't know if your booking tool can show live availability, and that changes the build a lot" sounds like someone protecting their budget.

Script: offering paid discovery after the first call

Copy it, then change the details so it sounds like you.

Hi [Name],

Thanks for the call today. I've got a good picture of what you want the new site to do. Before I give you a fixed price, there are a few things I need to pin down properly:

• [Unknown 1, e.g. whether your booking system can connect to the site]

• [Unknown 2, e.g. how many of the current pages are staying, and who's writing the new ones]

• [Unknown 3, e.g. which old URLs bring in search traffic and need redirects]

If I quoted today, I'd have to guess at those, which means either padding the price or arguing about scope halfway through. Neither is good for you.

So I'd suggest we start with a short paid discovery: [fee], delivered by [date]. You'll get a written plan covering the page list, content plan, technical requirements, what's in and out of scope, and a fixed quote for the build. It's yours to keep whether you go ahead with me or not. [Optional: If you sign the build by [date], the discovery fee comes off the build price.]

If that works, I'll send the discovery agreement over today.

[Your name]

If they ask for "just a rough number," give a wide range and say what it depends on. That usually makes the case for discovery on its own.

How does a paid discovery phase prevent scope creep later?

A paid discovery phase prevents scope creep by giving you a written, client-approved baseline: the pages, features, integrations, exclusions and assumptions. Once the build starts, every new request gets checked against that document. If it's in there, it's included. If it isn't, it's a change, and it gets priced and approved before anyone starts on it.

Most discovery advice stops too early. The document gets delivered and never opened again, so when the client asks for a members area three weeks into the build, nobody points out that "no logged-in areas" was on page four. Make it do its job:

1. Have the client approve it in writing. An email saying "approved" is fine. Without it, the document is your opinion.

2. Turn it into the build's scope of work. Copy the inclusions, exclusions and assumptions straight into the build contract. Don't rewrite them from memory.

3. Add a change rule. Say what happens to anything outside the scope. A short scope creep clause does this in a paragraph.

4. Check every new ask against it. Not just the big ones. Small asks add up, and working out what scope creep is costing you usually shows the small ones are the problem.

5. Price changes before work starts. Use a change request form so the ask, the impact and the client's yes are all in one place.

That's basic change control, just sized for a small studio. The APM describes change control as the process where requests to change the approved baseline are captured, evaluated, and then approved, rejected or deferred. Discovery is what gives you the approved baseline in the first place. Without it, there's nothing to compare a request to, and every conversation about what scope creep actually is turns into your memory against theirs.

What if the client wants to skip discovery?

Then write assumptions instead. If the client won't pay for discovery, put a clear assumptions list in your quote: page count, who writes content, which integrations, how many revision rounds. Say plainly that anything outside those assumptions will be quoted as a change. You get a thinner baseline than discovery would give you, but you still get one.

For example:

This quote assumes: 8 pages using 3 templates; you supply all copy and images by [date]; one contact form sending to one email address; no integrations with booking, CRM or payment systems; two rounds of design revisions. Work outside these assumptions will be quoted separately and started only after you approve it.

Then, when the client says "oh, it also needs to sync with our CRM," you don't need a hard conversation. You point at the assumption, and you send a price. Our guide on how to price a change request covers the maths, and the out-of-scope scripts cover the wording.

The same thing applies to revisions. If the assumptions say two rounds, the third round isn't a surprise to anyone. Here's how to charge for extra revisions once you get there. For the build itself, how to prevent scope creep in web design covers defining a revision round and naming one approver.

Example (hypothetical): a website with a booking integration

A small physio clinic wants a new website "with online booking." On the first call you learn they have a current site, use a third-party booking tool, and aren't sure how many pages they need. You can't quote the build honestly.

You offer a fixed-fee discovery. Your estimate:

At a rate of $100 an hour, that's a fixed discovery fee of $1,000, paid upfront, delivered in about two weeks. You offer to credit half of it if they sign the build within 30 days.

Discovery shows the booking tool only supports an embedded widget, so the build is simpler than the client feared. The plan lists 10 pages on 4 templates, the clinic writing its own service descriptions, the embedded booking widget, and redirects for 5 old URLs that get search traffic. Exclusions: no patient logins, no blog, no translation. You quote the build at $8,000.

Six weeks later, the client asks for a patient portal. You don't argue about it. "Patient logins" is in the exclusions the client approved, so it's a new piece of work, quoted on its own, and started only if they say yes. If a client keeps reversing decisions after sign-off, here's how to handle a client who keeps changing their mind.

A one-page discovery agreement outline

You don't need a long contract for a small discovery. You do need these lines in writing. Have a lawyer look over your standard terms once; this is a structure, not legal advice.

Discovery for: [Client], [project name]

Goal: Produce a written plan and a fixed build quote for [project].

Includes: [number] calls or interviews, review of [current site / analytics / tools], [list of deliverables], one review call on the final document.

Doesn't include: design, development, copywriting, or more than one round of changes to the discovery document.

Client provides: access to [analytics, CMS, tools], and the people listed for interviews, by [date].

Fee: [fixed fee], paid before work starts. [Optional: credited against the build if signed by [date].]

Delivery: discovery document by [date], assuming the client inputs above arrive on time.

Ownership: the client owns the discovery document and can use it with any provider.

Next step: the build quote in the document is valid for [number] days. Any build work starts only after a separate signed agreement.

The agreement has its own inclusions and exclusions on purpose. Without limits, discovery tends to grow into a free first draft of the website.

What happens after the discovery phase?

After discovery, you present the plan and the build quote, answer questions in one review call, and the client decides: go ahead, change the scope, or stop. If they go ahead, the discovery document becomes the scope of work for the build contract. If they stop, they keep the document and you've been paid for the work.

If the work turns ongoing after launch, the same rule carries into a monthly plan. See what's included in a website maintenance retainer and what belongs in a retainer agreement.

Where Creepless fits

Discovery gives you the baseline. The hard part is using it when requests start arriving by email, chat and calls. In Creepless, you load the agreed inclusions, exclusions, revision rounds and hour caps as that client's scope rules, and the client sends requests through a private link with no login. An AI scope referee marks each request Included, Extra or Needs review and cites the rule it used, and extras become a quote the client approves before work starts. The live demo shows how it works with sample data.

FAQ

Is a paid discovery phase worth it for small projects?

Usually not for very small, well-defined jobs. If you can scope the work from one call and you've done similar projects before, include the planning in your price. Paid discovery earns its keep when there are real unknowns, like integrations, migrations, unclear content or several stakeholders, where a wrong guess would cost more than the discovery fee.

How much should you charge for a discovery phase?

Build the fee from your own time estimate: calls, interviews, audits and writing hours, multiplied by your usual rate, plus room for one review round. Charge it as a fixed fee, paid upfront. Avoid basing it on a percentage of the build, because the build hasn't been scoped yet. That's what discovery is for.

Can a client take the discovery document to another agency?

Yes, if your agreement says they own it, and it usually should. It's an easier yes for the client when the plan is theirs either way. It also keeps you honest: the document has to be useful on its own, not a teaser that only makes sense if they hire you.

What if the client says other agencies do discovery for free?

Some do, often by folding the cost into the build price or doing a lighter version. You can explain what yours produces, offer a credit toward the build, or shrink it to a smaller paid audit. If they still won't pay, quote with a clear assumptions list instead and price anything outside it as a change.

The short version

Charge for a discovery phase when you can't quote honestly without research. Skip it when one call gives you enough. Sell it as a fixed fee with named deliverables and a delivery date, let the client own the result, and decide upfront whether the fee gets credited. Then the part most people miss: turn the approved discovery document into the build scope, and check every new request against it before anyone starts work. If the client won't pay for discovery, write the assumptions into your quote and treat anything outside them as a change. And if extras are already slipping through on current projects, the scope creep calculator shows what they add up to over a year.