A paid discovery phase before a web or app build: what you get

Short answer: A paid discovery is a short, fixed piece of work before a build in which the team researches the problem, the users and the constraints, then hands you documents you own: a defined scope, a prototype or wireframes, a list of risks, and an estimate you can actually rely on. It's worth paying for when the project is new, complex or expensive to get wrong. Ask for the deliverables in writing, make sure you can take them to another supplier, and be wary of a discovery that ends with nothing but a proposal to continue.

What "discovery" means

The term comes from product and service design. Nielsen Norman Group defines discovery as a preliminary phase that involves researching the problem space, framing the problems to be solved and gathering enough evidence and direction on what to do next. The UK government's Service Manual, a widely used method reference, frames it the same way: before you commit to building, understand the problem, your users and the constraints, and use what you learn to decide whether to go further. It also says plainly that you shouldn't start building during discovery, and that stopping at the end of discovery isn't a failure if the research shows that's the right call.

That last point is the heart of it. A good discovery is allowed to tell you not to build, or to build something smaller than you imagined.

What you should get: the deliverables list

Exact outputs vary by project, but for a typical business website, portal or app, expect most of these:

Problem statement and goals. One page in plain English: the problem, who has it, and what success looks like in measurable terms. The Service Manual gives a neat example of reframing a solution ("we need an interactive map") as a problem ("how can people find their nearest centre when they need an appointment?").
User research summary. Who was interviewed or observed (customers, staff), what they're trying to do, and where today's process breaks.
Current process map. How the work happens now, including the spreadsheets, emails and phone calls in between.
Constraints and integrations. Existing systems, data, contracts, hosting, legacy software, accessibility needs, and which constraints are hard and which can be worked around.
Scope with priorities. Features split into must-have for the first release, later, and won't do. This is the document that protects your budget.
Prototype or wireframes. Clickable screens or sketches of the key journeys, ideally tried with a few real users.
Technical approach. Recommended platform or stack, with reasons, and the main alternatives considered.
Risk and assumption log. What could derail the project and how to test or reduce each risk early.
Estimate and plan. A delivery estimate tied to the prioritised scope, with the assumptions behind it stated.
Recommendation. Proceed, proceed smaller, change direction or stop, with the reasoning.

NN/g adds a test worth applying to the final output: proposed solutions should be desirable to users, viable for the organisation and feasible with available technology. If the documents don't address all three, something is missing.

How to judge whether it's worth paying for

Discovery earns its keep when:

The project is new to you and the requirements are fuzzy.
Several departments or user groups have different needs.
There's existing software, data or integrations to deal with.
The build is large enough that a wrong turn would be expensive.
You need evidence to convince a partner, board or investor.

Discovery is less useful when:

The job is small and well understood, such as a five-page site or a change to an existing feature.
You already have a clear specification, research and designs from previous work.
The deadline is fixed by an event and the scope can only flex a little; a short scoping workshop may be enough.

Questions to ask before you agree

What exactly will I receive, in what format, and by when? Get the deliverables list in the contract.
Do I own the outputs? You should be able to take every document and prototype to another supplier.
Who will do the work? Names and roles of the people who'll interview users and make technical decisions, not just the salesperson.
Who will you speak to? Real customers and staff, or only me?
How long will it take, and how will I know it's finished? The Service Manual suggests setting a clear goal at the start to define when discovery is done.
What happens if you find the project shouldn't go ahead? Listen for whether they'd genuinely tell you.
How will the estimate at the end relate to the original budget conversation?
What do you need from my side? Access to staff, data, accounts and decision-makers. Discovery stalls without them.

Red flags

A discovery with no named deliverables, only "workshops".
No contact with actual users or staff who do the work.
Outputs locked in the supplier's tools or withheld until you sign the build.
The recommendation was obvious from day one (it's always "build everything").
Technical choices that match what the supplier always uses, with no alternatives discussed.
Discovery that quietly turns into building, before scope is agreed.
An estimate at the end with no stated assumptions.

FAQ

How long does a discovery phase take?

It depends on size. The Service Manual suggests around 4 to 8 weeks is typical for government services; small business projects are often far shorter. Agree the length and goal up front.

Can I run discovery with one company and the build with another?

Yes, if you own the outputs. Good discovery documents should be clear enough for any competent team to estimate from.

Is a discovery the same as a free sales consultation?

No. A consultation is about understanding whether to work together. Discovery is paid research and design that produces documents you keep.

What if the discovery says not to build?

Then it has probably saved you money. Use the findings to fix the process another way, or revisit later.

If you've been quoted for a discovery phase and want to know what a useful one should hand you, send us the scope you were offered.