How Long Does a Discovery Phase Take? Typical Timelines

October 19, 2026 · 7 min read

A software discovery phase usually takes 1-3 weeks for a small MVP, 3-6 weeks for a typical product with a few integrations, and 6 weeks or more for integration-heavy or regulated systems. The size of the product matters less than you might think. What usually decides the length is how quickly stakeholders are available, how much is unknown about the existing systems, and how many people have to agree. Here is how to read those ranges, what stretches them and a week-by-week plan for a four-week discovery.

Typical durations by project size

Published guides agree on the broad shape, though each one defines discovery slightly differently. The UK government's service manual says there is no set length, but that around 4 to 8 weeks is typical for its public-service discoveries, which include a lot of user research. Agency guides for commercial software quote shorter ranges: one describes discovery as typically three to six weeks, compressing to a couple of weeks for a simple product with a clear owner; another gives about three weeks for small projects and up to two months or more for large ones.

Put together, a reasonable planning range looks like this. Treat it as a rule of thumb, not a quote:

The ranges overlap because the deliverables differ. A discovery that produces requirements and a rough estimate is shorter than one that also produces wireframes, an architecture and a prototype. When you compare two offers, compare their lists of deliverables before you compare their week counts.

What stretches a discovery

The same product can take three weeks with one client and six with another. The usual reasons:

• Stakeholder availability. If the decision maker can meet once every two weeks, every decision takes two weeks. This is the most common reason a discovery runs long.
• Disagreement. Two departments that want different things will not settle it in a workshop. Discovery brings the disagreement to the surface; settling it takes as long as the organisation needs.
• Unknown systems. A legacy system with no documentation, an API nobody has tried, data whose quality nobody knows. Someone has to look, and access alone can take a week to arrange.
• Approvals outside the team. Security reviews, legal checks on data, procurement questions.
• Starting from nothing. Teams that start with decks, notes, past research and call recordings move faster than teams that start from a one-line idea.
• Scope that keeps growing. If every workshop adds a new module, the discovery is turning into product design. Agree on the boundary in week one.

Most of these are calendar problems, not effort problems. A discovery that needs 15 days of work can easily take six calendar weeks if the people needed are hard to reach.

What can run in parallel

You can shorten the calendar by not running everything in sequence:

• Access requests and system investigation can start on day one, before the workshops. Request repository, environment and API access in the kick-off email.
• Stakeholder interviews can run alongside reading the existing material.
• Architecture exploration can start as soon as the main flows are known; it does not need final requirements.
• Drafting the documents can start in week one. Write the background and problem statement from what you already have, and correct them as you learn.

What cannot run in parallel: settling priorities before the requirements exist, and estimating before the architecture and main integrations are understood. Those two set the minimum length of any discovery.

A week-by-week outline for a 4-week discovery

This plan fits a typical product with a few integrations and a client who can meet twice a week. It follows the ten sections of the discovery phase template.

Keep a short review at the end of each week with the decision maker. It catches wrong turns early and stops week four from becoming a week of rewrites.

To compress this to two weeks for a small MVP, merge weeks 1 and 2 and weeks 3 and 4, and drop anything the first release does not need. To stretch it for a complex system, the extra time usually goes into week 3: integrations, data and decisions.

Tools can shorten the writing, though not the meetings. Discovery Phase AI drafts the background, problem statement, goals, users and requirements from the files you upload (decks, documents, call transcripts, images) and gives each stage an AI quality score with suggestions. That cuts the time spent turning notes into documents. It does not replace the conversations in which stakeholders agree.

Signs you are done

A discovery is done when its outputs can support a decision, not when the calendar runs out. The GOV.UK manual frames it the same way: you have finished when you can decide whether to move on, and stopping is not a failure if the research shows that is the right call.

Practical signs:

• The decision maker has read the executive summary and agrees with it.
• The scope of the first release is agreed in writing, including what is out.
• Every Must requirement has acceptance criteria and traces to a goal.
• The estimate is a range with its assumptions written down.
• Open questions and risks each have an owner and a date.
• The next step is clear: build, run a smaller pilot, or stop.

These match the sign-off section of the discovery phase checklist:

If the calendar is up and these are not true, you have two honest options. Extend the discovery for a stated reason and a stated number of days, or close it with the gaps written down as open questions and risks that the first phase of the build will have to resolve. For the bigger picture of what discovery is for, see the discovery phase in software development.