The software discovery phase, in short
A software discovery phase is a short, separate piece of work before the build. It answers three questions: should you build this at all, what should you build first, and what could go wrong? It should end in a written recommendation you own. A good one is clear enough for another company to quote from, and it's allowed to say "don't build".
This guide is for founders and operations leads at UK and EU companies of 10 to 200 people. A development company has offered you a paid discovery phase, or you're wondering whether to ask for one before you commission custom software.
Most guides to the discovery phase come from development companies, and they list the documents you'll receive. We list them too.
Those guides skip two questions a buyer should ask before paying. Can the discovery end with "stop"? And can you take what it produces to another company?
We think both answers should be yes, and we're a studio that would like to build your software. Our software consulting starts from the same two answers.
What a discovery phase is for
A discovery phase exists to understand the problem before anyone commits to a solution. "You should not start building your service in discovery," says the UK government's Service Manual, which sets the standard for building public services.
The same page gives an example. Say a team is told to build an interactive map of contact centres. It should first reframe that as a problem: how can people find their nearest centre when they need a face-to-face appointment?
Once you write the problem down, a map becomes one answer among several. Reframing also includes "agreeing what is not part of the problem".
Most requests to a development company arrive as solutions: a portal, an app, a dashboard, "something with AI". Discovery turns the request back into a problem, then checks it against how the work really runs.
When we take a company through an AI project, we start by sitting with the team. We want to see how the work actually runs, rather than how the process document says it runs. The difference between the two is where most of the scope hides.
What a discovery phase should produce
A discovery phase should produce a short set of documents that let you decide, and let any competent company quote. The names vary between suppliers. The questions each document answers shouldn't.
| Output | Question it answers | How to tell it's good |
|---|---|---|
| Problem statement | What's wrong, for whom, and how will you know it's fixed? | Written in the words of the person who has the problem, with a measure: hours, errors or days |
| How the work runs today | Who does what, in what order, with which tools? | It includes the workarounds, and the spreadsheet nobody mentioned in the first meeting |
| Constraints | What can't change? | Laws, contracts, existing systems and data, each marked as fixed or negotiable |
| Options | What are the realistic ways to solve this? | At least one option isn't a custom build, and each option names its trade-offs |
| First release | What gets built first, what's left out, and what's done by hand? | A written list of what's out, not only of what's in |
| Risks and unknowns | What could break the plan? | Each risk ranked, with a cheap way to test it early |
| Estimate | How long, and with how many people? | The assumptions written down, and the least certain parts named |
| Recommendation | Build, change course, or stop? | A plain answer with reasons, one you could forward to your board |
The first-release row is where discovery meets scope. Our guide to what an MVP should include shows how to draw that line: cut features, and keep the foundations that are expensive to add later.
Production code is missing from the table on purpose. A clickable prototype can help test a risky idea with the people who'll use it, and some discoveries include one. Code written before everyone agrees on the problem tends to become the product by accident.
Ask for two documents, because they age at different rates
Ask for the output as two documents, not one. One holds the decision: the problem, the scope, what's out, and what "done" means. The other holds the evidence: interview notes, how the current systems behave, data samples and anything else learnt along the way, each item dated.
A decision should stay true for the length of the project. Evidence starts going stale the day it's written, because your systems, your staff and your suppliers keep changing. When both live in one document, a reader who finds three out-of-date details about the current system stops trusting the scope as well.
Kept apart, the decision document stays short enough to read in one sitting. The evidence document tells whoever builds from it which facts to re-check first.
A discovery phase is allowed to end in "stop"
A discovery that can only end in "build" is a sales stage. It has three honest outcomes: build what you asked for, build something smaller or different, or don't build.
The Service Manual says so directly: stopping at the end of discovery is "not a failure" when the evidence points that way. Its list of alternatives to building includes publishing web content and giving better information to face-to-face advisers.
In August 2025, the Home Office's digital team wrote about advising stakeholders not to move beyond discovery or alpha. In those cases the team found where "existing technology, tools or processes could meet user needs", and helped teams make better use of what they already had.
Commercial discovery has a structural pull the other way. The company running it usually hopes to win the build. You can't remove that interest, but you can bring it into the open. Before you agree to a discovery, ask the company what would make it recommend that you stop, and whether that has ever happened.
Our consulting page lists that outcome in plain words: "whatever the honest answer is, including that you do not need this yet". Sometimes the answer is to buy a product. Our comparison of custom software and off-the-shelf tools covers when building your own pays off. Of everything a discovery produces, a recommendation to spend less is the part you can check without technical knowledge.
Another company should be able to quote from the output
Test a discovery's output by asking whether another company could quote from it. If the documents only make sense to the people who wrote them, you've paid for one supplier's head start, not for a decision.
Public buyers have to manage that head start by law. Article 41 of the EU public procurement directive covers a company that advised a public buyer before a tender. The buyer must take measures so competition isn't distorted, including sharing the relevant information with the other bidders.
In the UK, section 16 of the Procurement Act 2023 requires public buyers to take steps so that suppliers involved in early market engagement aren't put at an unfair advantage. Where the buyer can't avoid the advantage, it must exclude that supplier from the award.
A private company isn't bound by either rule, but it can borrow the principle. Put three things in the discovery contract:
- The documents, diagrams and any prototype belong to your company, and you may share them with other suppliers.
- Everything arrives in formats you can open and edit, not only as a slide presentation.
- The estimate lists its assumptions, so another company can check them instead of starting again.
Discovery then works whoever builds: a studio, a freelancer or a developer you hire. Our guide to choosing an agency, a freelancer or an in-house developer covers that choice. Our consulting ends in a written recommendation you own, "so it is still useful if you take the work elsewhere".
What skipping discovery looks like
Skipping discovery rarely feels like a decision. It feels like starting quickly. Two public audits show where that leads. Both projects were far bigger than yours, and the pattern still applies.
In September 2013, the UK's National Audit Office reported on Universal Credit's early progress. The Department for Work and Pensions had tried "to develop processes and systems at the same time as defining policy requirements". Its auditors found that the department "has lacked a detailed view of how Universal Credit is meant to work", despite repeated warnings about the missing blueprint.
In early 2013 the department stopped work on plans for national roll-out, and the government ordered a reset. Writing the blueprint was one of the reset team's objectives. The department had chosen an agile approach, and agile delivery still needs someone to decide what the team is delivering.
In the US, the Government Accountability Office reviewed the contracts behind Healthcare.gov in 2014. To move fast, the agency ordered the build while key technical requirements were unknown. The unknowns included "the number and composition of states to be supported and, importantly, the number of potential enrollees". The GAO found that changing requirements, made worse by gaps in oversight, were the main cause of the cost increases, schedule slips and delayed features that followed.
Your project is smaller, but the unknowns are the same kind. Say you run a 40-person wholesaler and commission a customer ordering portal. Nobody has counted how many orders still arrive by phone, which system holds the current prices, or who approves a credit limit.
Each answer changes the build. A discovery finds them early, on paper. Without one, they surface during the build, one change request at a time.
How discovery changes the contract for the build
A discovery phase changes what kind of contract the build can have. Without one, a company can only fix a price by guessing, and it protects the guess with padding or with change requests. With a written scope and a list of assumptions, it can price the known parts firmly and name the uncertain parts as uncertain.
Healthcare.gov shows the other end. The agency used cost-reimbursement contracts, under which it had to pay the contractor's allowable costs "regardless of whether the system is completed". Discovery is how you get from "we don't know" to a scope firm enough to choose a contract type. Our guide to fixed price or time and materials sets out how to choose once you have that scope.
The discovery itself is usually easiest to buy as a fixed, time-boxed piece of work with a named list of outputs. You know what you'll receive, and when.
How long a discovery phase takes, and what sets its size
The Service Manual says "around 4 to 8 weeks is typical" for a public service, and that the purpose of the discovery should decide its length. A smaller company's discovery is often shorter, because it involves fewer people, systems and rules. The same factors set its size, and so its price:
- How many teams and roles the discovery has to interview.
- How many existing systems the project touches, and how clean their data is.
- Whether there's an existing codebase to audit first.
- Which rules apply, such as data protection, sector regulation or accessibility.
- How many people have to agree to the recommendation.
When a project starts from software that already exists, discovery starts with an audit of it. That's how we take over a codebase: an audit rather than a guess, then a written recommendation. It includes the case for rebuilding when that is genuinely the better path.
What to ask before you agree to a discovery phase
Send these questions to every company that offers you a discovery, and compare the answers in writing:
- What will we have at the end, listed document by document?
- Can we see a redacted example from a past project?
- Who will run the interviews, and will they be the people who would build it?
- Will you talk to the people who do the work, or only to managers?
- What would make you recommend that we stop, and has that happened before?
- Who owns the documents, and can we share them with other companies?
- What will the build estimate assume, and which parts will it be least sure of?
For the wider choice of supplier, our guide to choosing a software development company covers ownership, direct access to the engineers and what belongs in the written scope.
When you don't need a discovery phase
Not every project needs a separate discovery. Skip it in these cases:
- The job is small and defined, such as one change to one feature. A written description and a conversation are enough.
- You're choosing between products you can buy. A trial with your own data and your own people is the discovery.
- You need a website rather than an application. A good brief does the job, and our website brief template shows what goes in one.
- You already have a written scope that another company could quote from, because you or a previous supplier did the work.
Start with one page
Before you talk to anyone, write one page. Describe the problem in the words of the person who has it. Add who does the work today and how, what's been tried, what can't change, and how you'll know it worked.
Send it to the companies you're considering, and ask each one what its discovery would add to that page. Their answers will tell you whether you need a discovery at all, and which company is thinking about your problem rather than its build.
Questions
Who from our side needs to take part in a discovery phase?
The person who will make the decision, the people who do the work today, and whoever looks after the systems the project touches. Plan their time: interviews, follow-up questions and reading the drafts. A discovery that only talks to managers tends to describe the process document rather than the work.
How is a discovery phase different from the conversations before a quote?
A sales conversation gives a company enough to say whether it can help and roughly what the work involves. A discovery phase goes further. Someone interviews your team, reads your systems and data, and writes documents you keep. If a paid discovery produces nothing but a quote for the build, you've paid for the sales process.
Can we run the discovery ourselves?
Partly. You can write down the problem, how the work runs today, what's been tried and what can't change. That's the one-page start at the end of this guide. The parts that need an outside eye are reading the existing systems and data, judging what is technically risky, and estimating. An internal discovery also tends to skip the option of not building, because the people running it asked for the project.
What if discovery shows the project is bigger than we thought?
Then it has done its job while changing course is still cheap. The recommendation should show a smaller first release that still solves the core problem, and what the rest would need. Deciding with that in front of you beats finding out halfway through the build.
How we wrote this: drafted with AI, then checked and edited by the people who build our projects. Figures come from our own work or from the linked sources.