Most software projects that go badly wrong were mispriced and misunderstood before a line of code was written. The discovery phase exists to prevent that. Done properly it is the highest-leverage spend in the entire project. Done badly it is a paid sales process wearing a lanyard.

The difference is visible in what you are holding at the end. This article sets out the six artefacts a discovery phase should produce, and the signals that tell you it is not going to.

The test for a good discovery

Here is the single question worth asking: could you hand the output to a completely different development company and get a comparable estimate and a comparable system?

If yes, discovery produced genuine, portable understanding. If no — if the output only makes sense to the vendor who wrote it, or if it is mostly assurances that they understand your needs — then you have bought a proposal, not an analysis.

This test matters because it aligns incentives. A vendor confident in their work is happy to produce something portable. A vendor relying on lock-in is not.

The six deliverables

1. A written problem statement you recognise

Discovery should begin by restating your problem back to you, in your language, including the business context and the constraints. Not the solution — the problem.

This sounds trivial and is the most commonly skipped step. It routinely surfaces the fact that different stakeholders in the same organisation are describing different problems. Better to find that in week one than in user acceptance testing.

You should read this document and think yes, that is what we are trying to fix. If you find yourself translating it, discovery has not listened.

2. A process map of how work happens today

An honest map of the current state — including the spreadsheets, the manual steps, the person who knows how to fix the thing that breaks, and the exceptions everyone works around.

The exceptions are the point. Systems fail in production because the happy path was modelled and the twelve edge cases that make up a quarter of real volume were not. Those edge cases live in the heads of the people doing the work, and the only way to get them is to sit with those people. If nobody from the vendor spoke to an actual end user during discovery, treat the resulting estimate as fiction.

3. A scoped feature set with explicit exclusions

A prioritised list of what will be built — and, critically, a written list of what will not be built.

The exclusion list is the more valuable half. Scope disputes almost never arise over things that were listed; they arise over things both sides assumed. Naming exclusions forces those assumptions into the open while it is still cheap to resolve them.

Insist on it. A vendor reluctant to write down what is out of scope is preserving ambiguity to be resolved later, in a change request, at their discretion.

4. A technical approach with the trade-offs shown

Proposed architecture, major technology choices, integration points, and the data model at least in outline.

What separates a real technical approach from a shopping list is the reasoning. You want to see the alternatives that were considered and why they were rejected, in terms of your constraints — team skills, existing systems, compliance obligations, expected load, budget.

A document that names a stack without justifying it against alternatives is describing the vendor’s habits, not your requirements. Both may point the same way, but you should be able to tell the difference.

5. Risks, named and owned

Every project carries risk: a third-party API with poor documentation, data quality worse than anyone admits, a regulatory deadline, a key stakeholder who has not engaged, an unproven scaling assumption.

Discovery should list these explicitly, rate them, and say what will be done about each — de-risk it early with a spike, accept it, or design around it. Each risk should have a named owner on both sides.

A discovery output with no risk section is not a low-risk project. It is an unexamined one.

6. An estimate with its uncertainty attached

A single number with no range is not an estimate; it is a negotiating position. Real estimates come as ranges, with the assumptions that produce them written down, and with the specific unknowns that would move the number.

The most useful format we have found is a phased estimate: a tight range for the first phase, where understanding is deepest, and progressively wider ranges for later phases, with an explicit commitment to re-estimate as each phase completes. That reflects how knowledge actually accumulates on a software project.

Red flags during discovery

Watch for these while it is running, not after.

• Nobody asks uncomfortable questions. Good discovery is mildly adversarial. If the vendor accepts every requirement without probing cost, feasibility or whether it is genuinely needed, they are optimising for signing rather than for delivering.
• Only management is interviewed. Management describes the process as designed. End users describe it as it actually runs. You need both, and the gap between them is where budget disappears.
• The output is a slide deck. Slides compress out precisely the detail that matters. Ask for prose and diagrams you can circulate and argue with.
• The estimate arrives before the analysis. If a number appeared in week one and discovery is now working backwards to justify it, discovery is theatre.
• Everything is possible. Every real project involves trade-offs between scope, time, cost and quality. A vendor who never mentions one is deferring the conversation to a point where you have less leverage.
• No discussion of what happens after launch. Support, monitoring, handover and ownership are part of the system’s cost. Silence here means it has not been thought about.

How long, and how much

Discovery should be short and time-boxed — long enough to resolve genuine uncertainty, short enough that it does not become a project in itself. For most mid-sized systems, a few weeks is the right order of magnitude. If it is stretching towards months without producing artefacts, something has gone wrong.

It should also be paid and separately contracted. This is counter-intuitive to buyers who prefer free discovery, but free discovery is sales-funded, and sales-funded analysis reaches the conclusion that a sale is appropriate. Paying for discovery buys you an honest answer — including the answer that the project should not go ahead in its current form, which is sometimes the most valuable output of all.

Because it is separately contracted, you should also be free to take the artefacts elsewhere. If a proposed discovery agreement prevents that, ask why.

What discovery needs from you

Discovery is a joint activity, and the most common reason it produces weak output is not supplier incompetence — it is insufficient access on the client side.

To do it properly, a supplier needs three things from you. Access to the people who do the work, not only to those who manage it, and enough of their time to be interviewed and observed properly. Access to real data, or at least a realistic sample, because data quality assumptions are where estimates most often break. And a single decision-maker who can resolve conflicting requirements between departments.

That third one is worth protecting. Discovery frequently surfaces genuine disagreement inside an organisation about what the system should do — different teams wanting incompatible things, each convinced theirs is the obvious requirement. A supplier cannot resolve that; only you can. If there is nobody empowered to adjudicate, discovery will document the disagreement and the project will inherit it.

Plan for this before discovery starts. Name the decision-maker, book the interview time in advance, and clear the data access. Discovery phases that slip almost always slip waiting for people, not waiting for analysis.

Working with us

We run discovery as a standalone, fixed-price engagement that ends in the six artefacts above — yours to keep, and deliberately portable. Some clients continue with our software development teams afterwards; some take the output and build in-house; occasionally the honest conclusion is to buy an existing product instead.

If you are scoping a system and want the analysis done properly before committing budget, talk to us about a discovery engagement.