What a Discovery Phase Is, and Why It Is Not a Delay

What discovery is for

Estimating software is guessing about work nobody has done yet. The size of the guess depends almost entirely on how much is unknown, and at the point you first speak to a development firm, nearly everything is unknown — to them and, more often than anyone admits, to you.

Discovery exists to shrink that unknown before anyone commits to a number. It is the difference between "a customer portal, probably three to six months" and "these eleven screens, these four integrations, this data model, this many weeks, and here are the two things that could still move it."

The objection is always the same: this delays the build by three weeks. It rarely does. Three weeks of specification typically removes considerably more than three weeks of building the wrong thing, and it removes them from the expensive end of the project where changes cost the most.

What actually happens during it

A real discovery phase is mostly interrogation, not workshops. The bulk of the value comes from a small number of uncomfortable questions being asked early enough to matter.

• Problem definition. What is broken now, who feels it, and what do they currently do instead. If nobody has a workaround, the problem may not be real enough to pay for a solution.
• User interviews with the people who will actually use the thing — not only the person commissioning it. These two groups want different software surprisingly often.
• A technical audit of what already exists: systems to integrate with, data to migrate, the quality of that data, and who still understands it.
• Data modelling. Sketching the core entities and their relationships surfaces more hidden complexity per hour than any other discovery activity.
• The edge cases: permissions, failure states, what happens when two people act at once, what the regulator requires.
• Prioritisation. Everything named gets sorted into the first release, the second, and the list of things that were mentioned but should not be built.

Interface sketching happens too, but later and lighter than most people expect. Screens are easy to redraw. A data model that turns out to be wrong after four months of development is not.

What you should receive at the end

The deliverables are what separate discovery from a long sales process. Ask for these by name before agreeing to anything.

The portability test

Here is the one check worth applying to any discovery proposal. Ask: could I take these deliverables to another firm and get a comparable quote?

If yes, the output is real. It documents your product rather than the supplier's pitch, and it has value independent of who wrote it. If no — if the deliverable is a deck of themes, personas and a phased roadmap with no specification underneath — you have paid for a sales asset. That is the difference, and it is visible in the deliverables list before you sign.

What it costs, and what that buys

As an observed market range, discovery runs at roughly five to twelve per cent of the expected build cost, or a fixed fee in the region of USD 3,000 to 25,000 depending on the size and messiness of the problem. Duration is typically one to three weeks; beyond four, the phase has usually stopped converging and started expanding.

These are market ranges rather than any single firm's rate card, and the variable that moves them most is not project size but how much nobody currently knows.

The fee should be fixed. Discovery is one of the few phases where scope genuinely is knowable in advance, because the deliverables are documents. A supplier who wants to run discovery on time and materials has not defined its output.

When you can skip it

Not every project needs one, and pretending otherwise is how discovery earned its reputation as a billing exercise.

• You already have a written specification that another party could quote from. Then you have done discovery; do not pay for it twice.
• The work is genuinely bounded and inspectable — one integration against a documented API, a migration between two systems you can both see.
• The build is small enough that discovery would be a meaningful fraction of the total. Below roughly USD 15,000 of work, a long conversation and a written scope will usually do.
• You are testing demand rather than building a product, and the honest next step is a landing page and some conversations rather than any software at all.

Conversely, the case where skipping it is most tempting and most costly: replacing a system that people currently rely on. The behaviour of that system is not documented anywhere, it lives in the habits of the people using it, and finding that out after the replacement ships is how projects acquire a second budget.

Making it worth the money

Discovery is unusually sensitive to how the client participates. The same three weeks with the same firm produces very different documents depending on a few things you control.

1. Put a decision-maker in the room. Discovery generates decisions faster than most organisations make them; someone with authority has to be present or the output fills with open questions.
2. Give access to real users, not proxies for them. An hour with someone who does the job daily beats a day of internal speculation about what they need.
3. Hand over the messy artefacts — the spreadsheet everyone actually uses, the exported data, the process document that is out of date. These are more informative than any brief.
4. Say the budget out loud. Discovery's job is to fit a solution to a constraint; withholding the constraint means the plan comes back unaffordable and has to be redone.
5. Argue with the draft. The specification is meant to be contested while it is cheap to change. Silent approval is the most expensive form of agreement in this process.

If you are considering a build and are not sure whether you need discovery or already have what it would produce, send us what you have written down. It is usually a short conversation to establish which of the two situations you are in.