Scoping

What should a discovery phase include, and what does it cost?

Last updated 7 October 2026

Every supplier sells a discovery phase. Almost none of them publishes what it produces or what it costs, which puts you in the position of buying an unnamed thing for an unstated price before you have decided to buy anything at all.

What it is actually for

A discovery exists to turn a paragraph into something that can be priced, built and argued with. Before it, nobody — including you — knows what the thing is in enough detail to commit money to it. After it, three suppliers can quote the same project and land within twenty per cent of each other, which is the only circumstance in which comparing quotes means anything.

The UK government runs this phase on every digital service it builds and publishes how it works. Its Service Manual puts it plainly: discovery is about understanding the problem, the users and the constraints before committing to build, and it ends with a decision about whether it is even worth proceeding. The questions it tells teams to answer are the right ones for a commercial product too — who the users are, what constraints exist, and whether going further is cost-effective.

What you should get for the money

A discovery should produce artefacts, not a conversation. If what you receive is a slide deck summarising things you said, you have paid for minutes. The list below is what makes the next phase possible:

• A screen-by-screen scope. Every screen, and for each one the states that cost real time: empty, loading, error, offline, and what happens the first time somebody opens it with no data.
• An explicit out-of-scope list. The most valuable page in the document. Without it, every disagreement later is a negotiation rather than a reference.
• The integrations, named and investigated. Not “connects to your accounting system” but which system, which API, whether it can do the thing you need, and what it costs.
• An architecture decision with reasons. Native or cross-platform, which backend, where the data sits. Each with the reasoning written down, so the next person understands why rather than inheriting a mystery.
• A risk list. The three to five things most likely to go wrong, each with what it would cost.
• An estimate with a stated uncertainty range. Not a single number. A range, with the assumptions it depends on, so you can see which assumption breaking would hurt.

What it should cost

Price it from days, the same way you should read any quote. At the UK median contract rate:

Rule of thumb: discovery usually lands between five and ten per cent of the build it is sizing. Below five per cent it is probably a sales exercise. Above fifteen, ask what is in it.

Two conditions worth insisting on

You own the output. If the discovery belongs to the supplier, it is a lock-in device rather than a deliverable. The whole point is that you can take it to someone else — and the supplier who is comfortable with that is telling you something about how they expect to win the build.

It is separately priced and separately cancellable. Discovery that is only available as part of a signed build contract is not discovery, it is a deposit.

The two tests afterwards

Did it change the plan? A discovery that confirms everything you believed going in either was not needed or was not honest. Real ones produce at least one uncomfortable finding: a feature that costs four times what you assumed, an integration that cannot do what you were told, a simpler product that gets you the same outcome.

Can a stranger price the build from it? Hand it to another supplier without explaining anything. If they come back with questions you have already answered in conversation but not on paper, the document is incomplete — and you will be answering those same questions as change requests later.

What happens after discovery, and why the timeline is usually a function of team size rather than feature count, is on the MVP timing page.

Sources. Duration benchmark: GOV.UK Service Manual, “How the discovery phase works”, page last updated 21 June 2021, retrieved 7 October 2026. Day rate: ITJobsWatch, UK contract software developer, median £525/day, six months to 6 October 2026. The deliverable list, the day ranges and the five-to-ten-per-cent rule are my own, from running these, not published standards.