The discovery phase is the short stretch before you build where you decide what the first release must do, how it will be built and what it will cost. It’s crucial because the most expensive mistake in software is building the wrong thing well. For an MVP, a good discovery takes about a week and ends with a written scope, clickable screens, a technical plan and a fixed price. Larger public services take longer: the UK government’s service manual says around 4 to 8 weeks is typical.
This guide covers what discovery includes, how the agile discovery process runs day by day, who takes part, what you should get at the end, what goes wrong without it, and what it costs.
Discovery is where you learn about the problem before you commit to a solution. The GOV.UK Service Manual puts two rules plainly: don’t start building during discovery, and discovery is finished when you’ve decided whether to go on or stop. The manual doesn’t count stopping as a failure, and for a bad idea it’s also the cheapest way out.
In agile teams, discovery doesn’t end on day one of the build. The Scrum Guide Expanded, updated in January 2026, says discovery is never over and that its work should show up in the backlog like any other work. It also warns that discovery can be overdone: a team can turn into a “discovery factory” just as easily as a feature factory. That’s why a time limit helps. One focused week before the build, then short checks with users every sprint after it.
Why it matters: most new businesses don’t last. Of the US business establishments that opened in the year to March 2021, 47.2% were still operating in March 2026, according to the US Bureau of Labor Statistics. Of those that opened in the year to March 2025, 78.9% made it through their first year. Not every closure comes from building the wrong product. But a week of discovery is the cheapest place to find out that the plan doesn’t hold.
| Activity | Question it answers | What you get |
|---|---|---|
| Users and the main job | Who is this for, and what one job must it do? | A short written scope |
| Scope | What goes into the first release, and what waits? | An in and out list |
| Main user flow and screens | What will people click? | Wireframes, then designs in a clickable prototype |
| Technical plan | What stack, which ready-made parts, which outside services, at what monthly cost? | A technical plan with the main risks |
| The riskiest question | Could one technical problem sink the product? | A short test with real data |
| Backlog | What exactly gets built? | A backlog with hours for every item |
| Price and plan | What will the build cost, and when is each part ready? | One price and a week-by-week plan |
Our discovery sprint fits the whole process into 5 working days. From you, it needs a 2-3 hour kickoff on day 1, two 30-minute reviews on days 2 and 4, and a 1-hour readout on day 5.
In between, we agree on who the product is for and the one job it has to do, draw the main user flow, and design up to 6 main screens for one platform as a clickable Figma prototype. We write the technical plan. If one technical question could sink the product, we spend a day testing it, for example by running an AI model on 10-20 of your real examples or making a test call to an API you depend on. On day 5 you get the backlog with hours and one price for the build.
On a small discovery, one person can cover two of these roles. For a B2C product, design gets more of the week. For a technical product for specialists, the architecture does.
| Problem | What happens without discovery | What discovery gives you instead |
|---|---|---|
| Misaligned expectations | Three different products: the one you pictured, the one the team built and the one users will pay for | One written scope and clickable screens everyone has seen |
| Scope creep | The feature list grows every week, and so do the bill and the date | An in and out list, with later ideas parked in the backlog |
| Technical surprises | An integration, an app store rule or an AI cost breaks the plan mid-build | A technical plan and a test of the riskiest part |
| Unclear budget and time | Every sprint ends with a new estimate | A backlog with hours and one price for the build |
| A product nobody needs | Months of work on a guess about users | Early checks of the problem with real people |
Technical surprises are often outside your code. Apple says it reviews 90% of app submissions in under 48 hours, but more than 40% of unresolved issues come from one guideline, 2.1 app completeness, which covers crashes, placeholder content and missing information (Apple). A technical plan that names the store rules your app touches saves a rejected release later.
Discovery doesn’t replace talking to customers. Our sprint doesn’t include testing with users or market research, so pair it with problem interviews. Our problem interview checklist shows how to run them.
By the end of discovery you should hold documents you can take to any team. From our discovery sprint you get:
Not included: testing with users, designs for every screen, production code, market research, a logo or brand, and an investor deck.
It depends on the size of the problem. A public service with many user groups and old systems can need the 4 to 8 weeks GOV.UK describes. An MVP with one main job fits into one week.
Our discovery sprint is a fixed $3,000 for 1 week. If you then build the MVP with us, the $3,000 counts toward it in full. If you don’t, the files are yours, and any team can use the scope and backlog as a brief. A typical MVP with us then costs $5,000-15,000 and takes 2-4 weeks.
If you’re a founder deciding whether a week of discovery is worth paying for, read why startups need a discovery sprint, and when to skip one.
For context, across the agencies we checked for the Rocketech MVP Price Index 2026, the median promised MVP timeline is 6 to 12 weeks (45 agencies) and the median published price per week of MVP work is $3,618 (27 agencies). These are published prices, not what agencies charge after scoping.
Here is how one discovery played out. Subflare, an AI lead scoring product for B2B teams, came to us with an idea and a Figma file but no team. The whole product rested on one unproven technical bet.
The founder never paid for the next step before the last one had proved itself.
You don’t need to book anything to get a first number. Our project estimate turns your brief into user stories. You confirm what is in scope, and every hour in the budget traces back to a story you kept. We check the hours the model suggests against what our team actually books on finished projects, then multiply by our published rate of $39-55 an hour.
For market size, the estimate suggests customer groups and gives each one a TAM, SAM and SOM with a note on what the number covers. Treat them as hypotheses to test, not verified demand. That matters here, because market research isn’t part of the discovery sprint.
Get a free project estimate first, then use the discovery week to check it with people who will build the product and turn it into a fixed price. For internal systems and larger products, our custom software development starts with your process and a 2-4 week pilot on one workflow for $5,000-15,000.
The stage before the build where the team and the client agree on who the product is for, what the first release must do, how it will be built and what it will cost. It ends with a decision to build, change the plan or stop.
For an MVP with one main job, about a week. Our discovery sprint takes 5 working days. Larger services take longer: the UK government’s service manual says around 4 to 8 weeks is typical for public services.
A written scope, the main user flow and screens in a clickable prototype, a technical plan with the main risks, a test of the riskiest technical question where there is one, a backlog with hours, and a price and plan for the build.
Our discovery sprint is a fixed $3,000 for 1 week. If you build the MVP with us, the $3,000 counts toward the build in full. If you don’t, the files are yours to take to any team.
You can if the scope is small and already written down, with known users and no risky technical parts. Otherwise skipping it usually costs more than it saves, through scope creep, surprises mid-build and features nobody uses.
Discovery should resolve decisions about scope, integrations and acceptance, not promise that all uncertainty disappears. Review our software development service and the Hays case to prepare questions about the dependencies your discovery must investigate. Explore software development services and the Hays case study.
Discuss the unknowns your discovery must resolve
Start with an AI-assisted project brief covering scope, budget, market assumptions and risks. Review its hypotheses before making a commitment.
Carefully curated content for resourceful Devs, CTOs, and PMs. No spam.