Discovery Phase in Software Development: What It Produces

October 7, 2026 · 8 min read

A discovery phase is a short, fixed-length stretch at the start of a software project in which the team decides what to build, for whom, and roughly how and at what cost, before development begins. It ends with a set of documents that a developer, a buyer or an investor can read and act on. This article covers the discovery phase of a software project, not "continuous product discovery" (the ongoing habit of interviewing users while a product is live).

What a discovery phase is (and what it is not)

Discovery is a bounded piece of work with a start, an end and a deliverable. Its job is to replace assumptions with written answers: who the people involved are, what problem is being solved, what "done" looks like, what the system must do, and what the build will take. The UK government's service manual describes the same idea for public services: before you commit to building, you understand the problem that needs to be solved, and you do not start building during discovery.

It helps to separate it from its neighbours:

• Not development. Nothing shippable comes out. At most you get clickable or sketched screens and a diagram of the system.
• Not a proposal or a statement of work. A proposal prices a scope someone already assumed. Discovery is what lets the scope be written down with evidence.
• Not continuous product discovery. That is a permanent team habit. The discovery phase is a one-off project step, often paid for separately.
• Not market research. It may use some, but its output is a plan for one specific product, not a study of a market.

Other names for the same thing include "project discovery", "scoping phase", "inception" and "Sprint 0". The labels differ between teams; what matters is that the work and its outputs are the ones described below.

The steps, in order

Teams run these in slightly different orders, and the middle steps overlap. The sequence below is the one that causes the fewest reworks.

1. Collect what already exists. Decks, emails, spreadsheets, old specs, call transcripts, screenshots of the current tool. Read them before booking interviews, so the interviews ask only what the documents cannot answer.
2. Interview the people involved. Sponsors, the people who will use the product, and whoever has to run or integrate it. Ask what problem they have, what they do today and what would make them call the project a success.
3. Write the problem and the goals. One short problem statement, then goals with a way to measure each. If the goals cannot be measured, the next steps have nothing to be judged against.
4. Map users and flows. Who the user types are, the journeys they take, and the flows (step-by-step paths through a task) that matter most.
5. List requirements and constraints. What the system must do, how well it must do it (speed, security, availability), and what limits the options: budget, deadline, existing systems, regulations.
6. Sketch the architecture and record decisions. The main components, how data moves, and the choices that are expensive to reverse, each with the options that were compared and why one won.
7. Draw the key screens. Enough to confirm that everyone imagines the same product. Wireframes are usually enough.
8. Estimate and plan. Split the work into milestones, give each a range (for example 6 to 9 person-weeks, not "7"), write down the assumptions behind the ranges, and list the risks and open questions.
9. Review and decide. Walk the sponsor through the result. The outcome is one of three: go as planned, go with a smaller or different scope, or stop. Stopping is a legitimate result and a cheap one.

If you want a ready structure for these steps, the discovery phase checklist turns them into things to tick off, and the discovery phase template gives a section-by-section outline of the document.

Who takes part and what each person owes

Roles are fewer than the list suggests; on a small project one person covers two or three of them.

Most delays in discovery come from the first and last rows: a sponsor who cannot decide, or users who cannot be reached. Agree on both before the work starts.

What you should hold at the end

A finished discovery leaves ten things on paper. They are the ten sections of the discovery report that Discovery Phase AI produces, and they match what most agencies deliver under different names.

1. Stakeholders. Who is affected or decides, and what each one expects.
2. Background. The context and history that explain why the project exists.
3. Executive summary. One page a busy sponsor can read and forward.
4. Problem statement. The core problem, in a few sentences, with who has it.
5. Goals and success metrics. Outcomes, how each is measured, and the figures to keep watching after launch.
6. Users, journeys and flows. The user types, how they move through the product, and the key flows as diagrams.
7. Requirements. Functional and non-functional needs, each prioritised (for example Must, Should, Could) and linked to a goal.
8. Architecture and decisions. The system diagram plus a log of the decisions made and the options rejected.
9. UI screens. Wireframes or mock-ups of the key screens.
10. Roadmap, estimates and risks. Milestones with ranges, the assumptions behind them, and the open risks and questions.

To see what these look like filled in, open the example report. Its project, Fieldwise, is invented, so nothing in it describes a real company.

The test of a good set is portability: a different team should be able to pick it up and start building without a kickoff call to explain what you meant.

How long it takes and what it costs (short answer)

There is no standard figure, and the sources disagree. Treat everything below as a rule of thumb.

• Duration. The UK government service manual says around 4 to 8 weeks is typical for public-service discovery. Software vendors who sell discovery tend to quote shorter: one agency puts a discovery phase at 2 to 4 weeks. Larger or regulated systems take longer.
• Cost. The same vendor quotes a fixed fee of $5,000 to $15,000 for that 2 to 4 week range, and published figures from other vendors vary widely. The spread is real: scope, the number of integrations, technical unknowns and compliance needs move the price, and so does who is doing the work and where they are based.

A sensible way to use these numbers is as a check, not a budget: a small product with few integrations falls near the low end of both ranges, and a regulated system with many integrations falls well above them. Ask any vendor what is in the price and what you will be handed at the end.

When a discovery phase is not worth it

Discovery earns its cost by catching expensive mistakes early, so it pays less when the mistakes are cheap or already caught.

• The product is tiny and reversible. A one-screen internal tool you could rebuild in a week does not need a month of preparation.
• Everything is already written down. If you hold a current requirements document, an agreed architecture and a priced plan, repeating the work duplicates it. Review what exists instead.
• You are still testing whether anyone wants it. Interviews, a landing page or a prototype answer that cheaper and faster than a full discovery.
• The scope changes weekly by design. In a very early experiment, long documents go stale. Keep a light version: the problem, the goal and the first milestone.
• Nobody will decide. If the sponsor cannot commit time to answer questions, the output will be a polite guess. Fix that first.

A middle path exists for the doubtful cases: a short discovery limited to the riskiest part of the project, with a go or stop decision at the end.