The Discovery Phase: What to Expect Before Any Software Is Built
The discovery phase is a short, paid piece of work before any software is built. Its job is to understand the problem, the people who live with it, the constraints and the data, and then to decide whether to build anything, and if so, what. It should end with process maps, a list of users and needs, constraints, a data assessment, options with a recommendation, a first-version scope and a ranged estimate. It may also end with the advice to stop.
The UK Government’s service manual, one of the clearest public guides to the practice, opens with the principle: “Before you commit to building a service, you need to understand the problem that needs to be solved.” It is just as clear about the boundary: “You should not start building your service in discovery.”
The short answer
- Discovery is research and decision-making, not design of every screen and not a free sales meeting.
- It should produce outputs you own and could hand to another supplier.
- Stopping, buying a product or fixing the process instead are legitimate outcomes.
- Buy it as a fixed fee, for a fixed period, with named deliverables.
- Judge it by one test: could another competent supplier quote the build from its outputs?
What discovery is for
Most software projects that disappoint were built on assumptions nobody checked: about what users do, how the data looks, what the law requires or which system holds the truth. Discovery checks them while changing your mind is still cheap.
The UK guidance lists what to learn: your users and what they’re trying to achieve; the constraints you’d face, for example because of technology or legislation; and the opportunities to improve things. It names typical constraints as legislation, contracts, legacy technology, and existing processes and systems. For a business in Oman, the same list applies, with local specifics such as e-invoicing and personal data protection.
It also asks teams to understand “how much the problem is currently costing”. Without that number, nobody can say whether the solution is worth its price.
What a discovery should deliver
| Output | Why you need it | What good looks like |
|---|---|---|
| Process maps, current and proposed | Shows where time and errors go | Drawn with the staff who do the work; exceptions included |
| Users and needs | Decides what gets built and for whom | Roles, tasks, devices and languages, from interviews |
| Constraints | Prevents late surprises | Legal, contractual, technical and data limits, named |
| Data assessment | Migration is often the hidden cost | Sources listed, quality sampled, owners named |
| Integration list | Integrations drive cost and risk | Every system, what flows each way, how it connects |
| Options | Building may not be the answer | Do nothing, fix the process, buy, integrate or build |
| Recommendation | The point of the exercise | One option, with reasons and trade-offs |
| First-version scope | Keeps the build small and useful | What is in, what waits, and why |
| Ranged estimate | Lets you plan and budget | A range with assumptions, not a single date |
| Success measures | Lets you judge the result | Two or three measures you can already collect |
Mapping the process and writing requirements cover two of these outputs in depth.
How long it takes
The UK guidance says: “There’s no set time period for a discovery, but around 4 to 8 weeks is typical.” That figure comes from public services, which are often large and multi-agency. A focused business system with one department and a few integrations may need less; a company-wide platform may need more. The guidance’s own rule is the better one: “Let the purpose of your discovery dictate how long you spend on it.”
Stopping is a valid result
The most valuable sentence in the UK guidance is this: “It’s not a failure to stop at the end of the discovery phase if your research shows that’s the best thing to do.” It adds: “In fact, you’ll be saving time and money that could be better spent elsewhere.”
A discovery that can only ever end in a build is not research. Common honest outcomes include: the process needs changing before any software, a standard product covers the need, an integration between existing systems solves most of it, or the problem costs less than any solution would.
Own the outputs
Make sure the contract says the discovery outputs are yours: maps, findings, data assessment, scope and estimate. You should be free to take them to another supplier for a competing quote, or to shelve them for a year.
“A discovery you can’t take to another supplier isn’t a discovery; it’s the first instalment of a sale. Pay for it separately, own what it produces, and keep the right to walk away.” — Abdulqader Wahiba, founder and CEO of ZAWAT
ZAWAT’s published approach starts the same way. Its first step, Discover, is described as mapping “your processes, users, and goals into a clear technical roadmap — grounded in real requirements, not assumptions.”
Who should take part
- The owner of the result, who makes decisions and can say “no”.
- The staff who do the work, including the ones with the private spreadsheets.
- Finance and IT, for budgets, systems and access.
- The supplier’s team: someone to interview and map, someone who designs, and an engineer who can judge technical risk. A discovery run only by salespeople will recommend what they sell.
Plan for your people’s time. Interviews, workshops and data access are the inputs that decide how fast discovery goes.
How to buy a discovery
Abdulqader Wahiba suggests judging any discovery by one test: could another competent supplier quote the build from its outputs? These five terms make that possible:
- Fixed fee and fixed duration, with the deliverables listed in the contract.
- Access agreed in advance: which staff, which data, which systems.
- A mid-point check to confirm the direction and adjust the questions.
- A final presentation with the recommendation, followed by the documents.
- No obligation to proceed, stated in writing.
Red flags
- The proposal for discovery already names the solution and its price.
- Nobody asks to talk to the staff who do the work.
- The outputs are a slide deck you could not hand to anyone else.
- Every option in the final report leads to the same large build.
- The supplier offers discovery “free” as long as you sign for the build.
Frequently asked questions
How much should a discovery cost? There is no standard figure; it depends on the number of processes, departments and systems involved. Judge the price against the outputs and against the cost of building the wrong thing. A fixed fee for listed deliverables makes it easy to compare offers.
Can we skip discovery for a small project? For a small, well-understood piece of work, a short workshop and a written brief can be enough. For anything your operations will depend on, skipping discovery moves the uncertainty into the build, where it is more expensive.
Who owns the discovery documents? You should, and the contract should say so. Owning them means you can use them to get competing quotes for the build, or return to them later.
What happens after discovery? You decide: stop, buy, integrate, or build. If you build, the first-version scope and ranged estimate become the basis of the build contract, and the estimate is refined as requirements are completed.
Is discovery the same as writing a requirements document? No. Requirements are one output. Discovery also decides whether to build at all, and what the first version should contain, before anyone details every requirement.
Sources: GOV.UK Service Manual — How the discovery phase works
Thinking about a system and want the problem understood before anyone quotes? ZAWAT’s approach to custom software and business systems starts with a Discover step, so the build is quoted on what you actually need. Book a call.