The discovery phase: what it is and why it is worth paying for

A discovery phase is a short stage before development in which the team and the client work through the problem, the users and the constraints, turning an idea into documented scenarios, prototypes and a grounded estimate. You pay for it to avoid paying more later: a mistake caught on paper costs hours, one caught in code costs weeks.

Here is what discovery includes, what you get out of it and when you can skip it.

What is a discovery phase and why do you need it?

A discovery phase is research and product design before any programming. Its goal is to answer the questions everything else depends on: what exactly we are building, for whom, how much goes into the first release and what it will cost.

Without discovery these questions still get answered — just during development and at a higher price:

• the team writes code against incomplete requirements and reworks it after the first demos;
• a gut-feel estimate drifts from reality and the budget is renegotiated mid-project;
• integrations with external systems turn out harder than expected when half the product is already built;
• the first release includes things you could have launched without, while important ones get postponed.

Discovery does not guarantee the product will succeed — only the market can tell you that. But it sharply reduces the risk of spending money on a misunderstood problem.

What does discovery include?

Discovery includes interviews with the client and users, roles and scenarios, data and integration design, prototypes of key screens and a development estimate. The exact mix depends on the product, but the outcome is always a clear plan for the first release.

Activity	What we do	Output
Interviews	Talk to the client, future users and internal teams	Goals, metrics, current processes
Scenarios and roles	Describe who does what in the system	Scenario list with acceptance criteria
Prioritisation	Separate what launch needs from version two	MVP scope and a later backlog
Design	Data model, integrations, technical risks	Architecture outline, stack choice
Prototypes	Clickable mock-ups of key screens	A prototype you can show to users
Estimation	Estimate development by scenario	A quote with a range and a staged plan

Scenarios follow the format we described in how to write a software requirements specification: user steps, system responses, alternative paths and acceptance criteria.

Photo: Unsplash

How long does discovery take and what does it cost?

For a typical web product, discovery takes us two to four weeks and costs roughly 10–15% of the first release budget — our own benchmark, not a rule. For a small website it fits into a few meetings; for a product with a dozen roles and integrations it can take more than a month.

What drives the duration:

1. The number of user roles and scenarios.
2. The number of external integrations and the quality of their documentation.
3. How quickly the client answers questions and makes decisions.
4. Whether the prototype needs testing with real users.

The same share for discovery and design appears in our MVP estimate breakdown: it is not an extra cost but work that will be done anyway — the only question is whether before the code or during it.

Why discovery is worth contracting separately

A separate discovery contract works in the client's favour. The output — scenarios, prototypes, architecture and estimate — belongs to you, and you can take it to another vendor or compare several proposals on the same basis. It is also a cheap way to see how a team works before committing to a large project.

What does the client get at the end?

The client gets a set of documents any team can use to estimate and start development. A good discovery output makes sense without its authors: you can hand it to a new developer, an investor or another vendor.

A typical package:

• a product description, goals and success metrics;
• roles and scenarios with acceptance criteria;
• a clickable prototype of key screens;
• a data model and an integration map;
• stack and infrastructure recommendations with reasoning;
• the first release scope and a backlog for later ones;
• a quote with a range and a staged work plan.

When can you skip discovery?

You can skip or shorten discovery when the problem is already well described: there is an up-to-date specification, the product is developed through an established process, or it is a small website without complex logic. Skipping it to save money when requirements are vague is a bad idea.

When the stage really is unnecessary:

• improvements to an existing product where the team knows the system and the business;
• a landing page or corporate site with a ready structure and designs;
• the client has its own analysts and detailed, validated requirements.

When skipping it is risky:

• a new product that exists only as an idea and a few screens in someone's head;
• many integrations or unusual business logic;
• several stakeholders with different expectations;
• a tight budget where it is crucial to know exactly what goes into version one.

If you are choosing a vendor, discovery is a convenient pilot: it shows how the team asks questions and keeps deadlines. More on that in how to choose a software development vendor.

In short

• Discovery turns an idea into scenarios, prototypes and a grounded estimate before any code.
• It typically takes 2–4 weeks and about 10–15% of the first release budget (our benchmark).
• The output belongs to the client and can go to any team.
• Skip it only when requirements are already detailed and validated.
• Discovery is the best pilot stage for testing a vendor.