Discovery phases: what they should produce and how to tell a good one from an expensive one

01What discovery is actually for

The purpose of discovery is uncertainty reduction, and that is measurable. Before discovery, a substantial build can honestly only be estimated to plus-or-minus 100%. After a competent discovery it should be plus-or-minus 20-30%, and you should be able to point at which specific investigations moved the number.

That framing matters because it tells you what to buy. You are not buying requirements documentation. You are buying answers to the three or four questions that could double the cost, which almost always concern integrations, data quality, non-functional requirements and undocumented behaviour in systems you already own.

02What it costs, and how long it should take

Discovery is normally 4-10% of the expected build cost. Below that it is too shallow to move the estimate; above 12% you are paying for the build in instalments without getting any software.

Duration is the more important control. A discovery longer than six weeks has usually lost its way, because the questions that matter most get answered in the first fortnight and the rest becomes documentation for its own sake.

03The deliverables that count

The test of a discovery is portability. If you took the output to a different vendor, could they price and build from it without repeating the work? If not, you bought a relationship rather than an asset.

Slide decks fail this test. So do 80-page requirements documents that describe intentions without resolving any of the technical unknowns beneath them.

04Signals of an expensive discovery

Discovery goes wrong in recognisable ways, and all of them are visible within the first week if you are watching for them.

• No engineer touched your code or your data - it was all interviews and workshops.
• The team is mostly analysts and account staff, with an architect billed at 10% who attends the readouts.
• The output describes the what in detail and never resolves a single how.
• Every risk is listed and none of them is investigated or retired.
• The estimate arrives as a single number with no range and no assumptions.
• The proposed build team shares no members with the discovery team.

05How to run one that earns its money

Structure discovery as a series of questions with owners and deadlines, not as a phase with a report at the end. Write the questions down before it starts, in priority order by how much cost each one could move.

Give the team access on day one - repositories, a data sample under NDA, the staging environment, and the two or three people who actually know how the current system behaves. Access delays are the leading cause of a discovery that produces nothing: two weeks waiting for a database credential inside a four-week engagement is half the budget spent on waiting.

• Write the top five estimate-moving questions up front, and grade the answers at the end.
• Insist that at least one integration is spiked against the real API, not a specification.
• Sample the actual production data - quality problems are found by looking, never by asking.
• Fix the non-functional numbers now: concurrent users, data volume, retention, residency, uptime target.
• Require the estimate as a range with a named list of what would push it to the top of that range.
• Agree in advance that you may take the artefacts elsewhere.

06When to skip discovery entirely

Discovery is not always worth buying. If the work is genuinely small, bounded and well understood - an integration against a documented API, a defined migration between known endpoints - a paid discovery costs more than the risk it removes. Spend a day scoping it and start.

The inverse is also true and more expensive. Anything touching a legacy system nobody fully understands, anything with a data migration, and anything where compliance scope is unsettled will be mis-estimated without discovery by a margin far larger than the discovery fee. In those cases skipping it does not save money, it moves the cost to a change request later at a worse negotiating position.