What should a founder require from a supplier’s discovery phase before saying yes to the build?
A good discovery phase should leave you with evidence, not just opinions. Here is how founders can judge whether a supplier has reduced risk, clarified scope and handed back something another team could actually build from.
On this page
Why it mattersWhat to ask forHow it worksOwnershipTrade-offsNext stepsIn short
- Discovery should reduce uncertainty, not create a polished story.
- Ask for validated needs, not just workshop notes.
- A useful discovery phase can end with a stop decision, not only a build recommendation.
- The handover matters: decisions, assets and ownership should be easy to transfer.
- If the supplier cannot show the outputs, discovery may be too vague to trust.
Discovery is often sold as a short, sensible way to reduce risk before a build. That is true, but only if it produces something useful. For a founder, the real question is not whether the meetings were thorough. It is whether the supplier leaves you with enough evidence and structure to make a better decision.
GOV.UK guidance treats discovery as the phase for understanding users, testing whether anything needs to be built at all, and deciding whether to move forward. That is a useful standard for commercial software work too. If discovery is done well, you should finish with clearer needs, a better-shaped problem, a small prototype direction, an initial backlog and enough ownership detail that another team could take over if needed.
Discovery is only useful if it changes the decision
A discovery phase should do more than collect opinions and produce a slide deck. Its job is to reduce the chance that you fund the wrong build, the wrong scope, or the wrong delivery partner. GOV.UK guidance is clear that discovery is about understanding the user problem and deciding whether anything needs to be built at all.
That means a good discovery output is a decision aid. It should help you decide whether to proceed, what to build first, what to leave out, and what assumptions still need testing. If you cannot point to those decisions at the end, the discovery has probably not gone far enough.
- Validated needs, based on research or evidence, not just internal preference.
- A clear first prototype or concept direction that answers the riskiest question.
- An initial backlog or scope outline that another team could use.
- Ownership notes covering assets, accounts, data and next-step responsibilities.
- A decision record that shows why the build should, or should not, go ahead.
The concrete outputs you should expect
- 1
Validated needs
You should get a clear statement of the problem being solved, who has it, and what evidence supports that view. In plain terms: what was learned from users, customers, internal staff or process review that makes this worth building?
- 2
A prototype or tested direction
Discovery should usually end with at least one tangible direction. That might be a clickable prototype, a service flow, a rough technical approach or a simpler test. GOV.UK’s playbook separates discovery from alpha, where prototypes are developed and tested with small user groups.
- 3
An initial backlog
You do not need the full delivery plan, but you do need a sensible starting point. The Planning Data Service handbook treats a refined backlog as a concrete handover output between discovery and delivery.
- 4
Ownership and handover notes
A supplier should record what has been decided, what remains open, where assets live and who owns what. Home Office guidance on on-boarding and off-boarding is a good reminder that ownership transfer should be explicit, not assumed.
- 5
A clear recommendation
The supplier should say whether to proceed, pause, change direction or stop. Stopping after discovery is not failure if the evidence points that way.
How to judge whether the work was actually de-risking
Discovery that helps
Shows the problem clearly, tests assumptions, narrows scope, and ends with usable outputs that support a build decision.
Discovery that does not help
Produces broad observations, generic suggestions and a proposal to build without showing what was learned or what changed.
A supplier does not need to solve everything in discovery. In fact, trying to do so is often a warning sign. Discovery should frame the work, expose uncertainty and narrow the list of unknowns. If everything still looks equally uncertain at the end, the phase has probably not been structured well enough.
It can also reveal that software is not the best answer. GOV.UK guidance notes that a different, cheaper intervention may be better, such as improving content, changing a process, using a campaign, or exposing an API. That matters for founders because a good supplier should be willing to tell you when not to build.
- Good discovery makes the problem smaller and clearer.
- It should reduce the number of unknowns before money is spent on build work.
- A supplier who can stop or redirect the work may be more useful than one who always says yes.
Ownership and handover should be visible
Founders often focus on scope and cost, then discover too late that the real risk is ownership. If the supplier keeps the important material in private tools, leaves key decisions undocumented, or does not hand over accounts and assets cleanly, the next stage becomes more expensive and fragile.
Good handover is not an admin task. It is part of de-risking. The planning and UCD guidance both point toward shared documentation, clear transfer of assets, and enough structure that another team can pick up the work.
0 of 5 complete
What good discovery gives you, and what it cannot guarantee
What you gain
Lower build risk, clearer scope, a better sense of priority, and a stronger basis for choosing a supplier or changing direction.
What you do not get
A guarantee that the product will work, a fixed final price for every future change, or proof that users will adopt the finished build.
This is where realistic expectations matter. Discovery is meant to improve the next decision, not to remove all uncertainty. A supplier that promises certainty is over-selling the phase. A supplier that can show what was tested, what remains open and what the next phase should prove is being more useful.
For founders, that makes discovery a commercial tool as much as a technical one. It helps you choose whether to proceed, what kind of build to fund, and whether the supplier has the discipline to hand over work properly.
What to do before you approve the build
0 of 6 complete
If the supplier answers these questions clearly, you are closer to a sound decision. If they cannot, the discovery may have been too light, too broad or too presentation-led. At that point, it may be worth asking for a tighter discovery scope before committing to the full build.
About the author
Nixim Team, Product Engineering
Practical guidance from Nixim on building software, working with AI and running dependable cloud systems.