What a paid software discovery phase should deliver

Discovery exists to make big decisions while they are cheap

Discovery, also called scoping or inception, is a short paid phase before a software build. Its job is to remove the uncertainty that makes estimates unreliable and to settle the big decisions while they are still cheap to change. Changing a decision on paper costs a conversation; changing it after the code is written costs rework.

Early software estimates are wide, and they narrow only as decisions remove uncertainty, an effect often called the cone of uncertainty. Meetings alone do not narrow them. Discovery is worth paying for when it forces those decisions: what the product must do first, which constraints are fixed and which technical risks are real.

Agree what you will receive before discovery starts

Buy discovery like any other deliverable: a fixed duration, a fixed price, named people and a written list of outputs. If a partner cannot say what you will hold at the end, the phase can drift into open-ended workshops. A complete set of outputs usually covers the following.

• A problem statement: who the users are, what they need and how success will be measured
• Scope for the first release: what is in, what is out and what is deferred
• The key user journeys, sketched or prototyped where they are uncertain
• An architecture outline: main components, integrations, data and hosting, with the options considered
• A risk register ranking what could make the project fail, and how each risk will be handled
• An estimate as a range with its assumptions, and a first milestone with acceptance criteria
• A decision log recording what was decided, by whom and why

Look for decisions, not a pile of documents

A discovery report can be long and still decide nothing. Read it for commitments: which features are in the first release and which are not, which technology and hosting choices are made, which integrations are needed, and which questions remain open, each with an owner and a date.

A useful signal is what the partner advised against. If the scope is larger at the end than at the start and nothing was cut, discovery has probably recorded your wish list rather than tested it. Sometimes the right conclusion is to buy an existing product, build less or not build at all, and a good discovery phase says so.

The riskiest assumptions should be tested, not only listed

Every project rests on a few assumptions that would change everything if they were wrong: an external API that does not support the operation you need, data that is messier than expected, a performance target the chosen design cannot meet, or users who will not change how they work.

Ask the partner to name those assumptions early and to test the worst of them during discovery, with a technical spike, a clickable prototype or a working session with the people who run the system in question. A risk that has been tested is information. A risk that has only been written down is still a guess.

An honest estimate is a range with its assumptions attached

A single number at the end of discovery hides the uncertainty that remains. Ask for a range for the first release, broken down by main component, with the assumptions that would move it up or down. For example: the estimate assumes the payment provider's API already supports partial refunds; if it does not, add the integration work listed separately.

Ask which parts of the estimate are firm and which are still uncertain, and how the commercial model will treat each. Firm parts can be priced as fixed; uncertain parts need a budget and a point where you decide again. The first milestone should be specified well enough that it could be delivered at a fixed price.

Keep an exit ramp at every step

Discovery is also the cheapest moment to leave. Make sure you own everything it produces, from documents and diagrams to prototypes and code, and that the outputs are written for any competent team, not only for the partner who wrote them. You should be free to build with that partner, hand the results to another team, build in-house or stop.

Carry the same idea into the plan that follows: a first milestone with acceptance criteria, then a decision point where you can continue, change course or end the engagement. This is how we start projects at SDK Enterprises: a written scope, a fixed first milestone and the named engineers, so you see the plan before committing to a larger budget. When you only need advice, you get a written answer your own team can act on, whether or not you build with us.

Six questions that show whether discovery was worth paying for

When the phase ends, check the results against these questions. If most answers are yes, the money bought clarity. If most are no, you paid for workshops.

• Could another team start building from these outputs without repeating discovery?
• Did the partner talk to users and to the people who run the systems involved, not only to the sponsor?
• Were the riskiest assumptions tested, with the results written down?
• Is the estimate a range with clear assumptions rather than a single number?
• Was something cut, deferred or challenged?
• Is the first milestone specified well enough to be accepted or rejected?

FAQ