What should a founder ask before paying for discovery so it improves the build decision?
A practical founder checklist for judging whether a discovery phase will reduce scope risk, clarify assumptions and support a better build decision before any delivery starts.
On this page
Why it mattersAsk thisScopeDeliverablesOwnershipTimelinesRed flagsUse it wellNext stepIn short
- Ask what decision the discovery is meant to enable.
- Check which assumptions will be tested, not just which meetings will happen.
- Make sure you will receive usable documentation, not only a presentation.
- Confirm scope boundaries, ownership and handover up front.
- Treat fixed timelines and prices as estimates unless the supplier has clearly scoped them.
Discovery should do more than open a project. For founders, the real question is whether it will reduce uncertainty enough to make the next build decision better. Good discovery clarifies the problem, tests risky assumptions, surfaces constraints, and leaves you with something usable even if you do not continue immediately. Government guidance treats discovery as the phase for understanding the problem, the users and the constraints before committing to build, with the output helping decide whether to move forward. That makes it worth checking the supplier’s process before you pay.
Why discovery is worth checking carefully
A discovery phase is not there to impress you with delivery language. Its job is to help you understand the problem well enough to choose the right next step. In public service guidance, discovery is used to understand the problem to solve, the users, the constraints and the opportunities before any build is committed. That matters for founders because early product decisions are often more expensive to change later than they first appear.
If a supplier’s discovery process is well designed, it should help you avoid building the wrong thing, over-scoping the first release, or discovering too late that an important constraint was missed. It should also make assumptions visible. The point is not certainty. The point is a better decision.
Questions to ask before you agree to discovery
0 of 8 complete
These questions matter because discovery should narrow choices, not widen them. A good supplier can explain how they will move from uncertainty to evidence. A weak one tends to describe activity instead of outcomes.
Check the boundaries before work begins
One of the most useful things discovery can do is draw a boundary around the work. That includes what is in scope, what is deliberately out of scope, and what will be left for a later phase. Procurement guidance and marketplace service definitions both treat discovery as a way to better understand the problem, surface risky assumptions and prepare for the next delivery phase.
Good boundary setting
Defines the business problem, the likely users, the main constraints and the decision the phase must support. It also states what will not be attempted yet.
Weak boundary setting
Talks about “exploring the idea” without saying which choices will be made, which risks will be tested or which deliverables you will receive.
A clear boundary protects your budget and your time. It also helps the supplier stay honest about what discovery can and cannot tell you. Discovery should reduce uncertainty, but it cannot remove every unknown.
Check what you will actually receive
- 1
Problem definition
A concise explanation of the problem in business terms, not just technical terms.
- 2
Assumptions and risks
A list of the assumptions that matter most, and which ones were tested.
- 3
User and workflow evidence
Notes from interviews, observations or existing data that show how the current process really works.
- 4
Options or recommendations
A sensible next-step recommendation, with trade-offs explained.
- 5
Handover material
Enough documentation for you or another team to continue without starting from zero.
You do not need a huge pack of documents. You do need enough clarity to act on. Government guidance on discovery and service assessment makes clear that discovery is about understanding whether the team really understands the problem before moving on. That means the artefact should support a decision, not simply record meetings.
Agree ownership and handover from the start
Founders should check what happens to the work when discovery ends. Who owns the notes, diagrams, prototypes, data mappings and recommendations? Will you receive the source files? Can another team use the material without asking the original supplier to explain it all again?
This matters because discovery is often sold as a short phase, but the outputs should still be useful later. If the supplier expects to continue into build, that is not a problem by itself. The risk is when the discovery output is only legible to the people who created it.
Ask for
Editable documents, clear diagrams, decision notes, and a short summary of what was proved, assumed or left unresolved.
Avoid
Hidden dependencies, vague diagrams, or recommendations that only make sense if the original team stays involved.
Treat time and cost as estimates, not guarantees
You may see supplier pages describing discovery as a short, time-boxed phase. That can be reasonable, but it should never be treated as a universal rule. Public procurement and marketplace materials show that discovery length varies with scale and context, and the evidence is stronger for its role in decision-making than for any single fixed duration or outcome.
| Check | What a sensible answer sounds like | Why it matters |
|---|---|---|
| Timeline | We can explain why this discovery needs this length and what would shorten or extend it. | Helps you judge whether the plan is realistic. |
| Price | We can break down what is included and what is excluded. | Prevents hidden extras and scope drift. |
| Output | You will receive specific artefacts that support a build or stop decision. | Shows the phase has a purpose beyond research. |
| Dependencies | We need access to users, data or stakeholders to do this properly. | Makes assumptions visible early. |
Warning signs that discovery may not help
- The supplier cannot explain the decision the phase will support.
- The proposal lists activities but not deliverables.
- They are unwilling to say what is out of scope.
- They promise certainty rather than reduced uncertainty.
- They cannot explain how findings will be handed over to your team.
- They push into build before the problem is properly defined.
How to get value from discovery without overbuying
The best use of discovery is often modest. It should help you decide whether to build, what to build first, and what to leave for later. In some cases, the right outcome is a smaller MVP, a different workflow, or no build at all. That is not failure; it is evidence.
For founders, the most helpful discovery is usually one that ends with a clear recommendation and a clear next step. That could be a scoped MVP, a prototype for a risky assumption, or a pause while you gather more evidence. The point is to avoid spending build budget on unanswered questions.
- Discovery should improve the build decision, not delay it without purpose.
- Ask for assumptions, constraints, deliverables and handover details before you pay.
- Prefer plain-language recommendations over broad promises.
- Treat discovery as a risk-reduction step, not a guarantee of success.
What to do next
Before you buy discovery, write down the decision you want it to support, the biggest unknowns, and the outputs you need to see before you are comfortable progressing. Then ask the supplier to map their process to those needs. If they can do that clearly, discovery is more likely to help. If they cannot, you probably do not need more process yet; you need a better definition of the problem.
About the author
Nixim Team, Product Engineering
Practical guidance from Nixim on building software, working with AI and running dependable cloud systems.