What a Discovery Phase Should Produce Before Development Starts

A discovery phase is the structured planning stage before development begins, during which the team defines the problem, tests assumptions, and documents what will be built. It should produce a written problem statement, a prioritised list of features, a draft technical architecture, and an estimate whose assumptions are clear enough that a developer could start work without asking basic questions. If you end discovery still unsure what will be built, the phase was not finished.

What should a discovery phase deliver?

A discovery phase should deliver a problem statement, a prioritised feature list, a draft technical architecture, a data model, a delivery roadmap, and an estimate with visible assumptions. Each artifact removes a decision that would otherwise interrupt development later.

You can recognise a finished discovery phase by the quality of its artefacts, not by the number of meetings held. Each item below earns its place by being usable later, not by looking complete in the moment. The most useful outputs are:

• Problem statement. One or two sentences describing who the software serves, what pain it removes, and how you will measure success. If this statement still changes after week one of the build, the estimate is meaningless.
• User stories and acceptance criteria. A user story is a short description of a feature written from the perspective of the person who will use it. Acceptance criteria are the conditions a feature must meet before it counts as done. Together they turn a feature name into a testable promise.
• Prioritised backlog and out-of-scope list. A backlog is the ordered list of features and fixes the team will work through. The order should reflect user value and risk, not convenience. The out-of-scope list names what you will not build in the first release, and it is your main defence against scope creep, the slow expansion of requirements that erodes budgets.
• Draft technical architecture. This is the high-level structure of the software, including its main components and how they communicate. A non-technical founder does not need to design it, but you do need to see that a senior developer has thought it through.
• Data model. This describes the types of information the system stores and how those records relate to each other. A flawed data model is the most expensive mistake to fix later, because every feature sits on top of it.
• User research notes. These are records of interviews or observations with real users. The notes matter more than the summary of findings, because they let the build team verify interpretations instead of accepting them blindly.
• Risk register. This is a list of the biggest threats to the project, with a mitigation for each. Custom software fails more often from unmanaged risk than from programming errors.
• Delivery roadmap and estimate. This is the sequence of releases and a cost figure built from the scope above, with explicit assumptions about team size and timeline. It should also name the minimum viable product, the smallest version of the software that delivers real value to users.

Anything not in this list is decoration. Discovery documents exist to be read by developers, not admired by stakeholders. If an output cannot survive contact with a build team, it does not belong in the phase.

How long does a discovery phase take?

A typical discovery phase takes two to six weeks, run by a team of two to four people. The range depends on the number of user roles, the amount of existing research, and how quickly stakeholders answer questions.

Two weeks is realistic for a single-role tool with a clear audience and few integrations. Six weeks is more common for a platform with several user roles, external payments, or connections to other systems. Integrations, which are links between your software and a third-party service such as a payment provider, add the longest review time because the external system has its own rules and constraints.

The team is typically one product owner, a designer, a senior developer, and a stakeholder who can answer business questions within a day. The developer must be present from the start. Without one, discovery produces a wishlist, not a plan.

How much should you budget for discovery?

Budget roughly 5% to 10% of the expected build cost for discovery, spread over two to six weeks. A small build of about $50,000 would then carry a discovery fee of $2,500 to $5,000.

Think of the fee as buying certainty, not documents. An estimate produced before discovery can swing two to three times the final cost, because the scope was still a conversation rather than a specification. An estimate produced after a proper discovery phase is typically within 20% of the final number. That tighter range is the return on the 5% to 10% you spent.

The difference shows up when you compare a weak discovery with a strong one across the same criteria. Both paths start with the same idea, and they diverge at the first difficult decision.

This comparison also shows who should do the work. A discovery phase that ends with a slide deck of trend lines has not delivered anything usable. The output must be a specification that a developer outside the room can read, cost, and build.

SaaS, short for software as a service, is software delivered over the web on a subscription model. If you commission a custom SaaS platform, the specification from discovery is what you will hand to the team that quotes the build. The quality of that handover determines whether the estimate is honest or hopeful.

Who should run the discovery phase?

A mix of internal product owner and outside facilitator works best for most builds. Internal-only discovery saves money but inherits blind spots, while an agency facilitator brings patterns from many projects and the freedom to challenge assumptions.

Discovery can be facilitated internally, by an outside agency, or by a solo consultant. Each option changes the quality of the output, so the choice deserves as much thought as the budget. The trade-offs are below.

For most custom builds, the best value comes from a mix: an internal product owner who makes decisions, and an outside facilitator who has run discovery before. The outsider is useful precisely because they do not share your assumptions. They will ask the questions that feel obvious once asked but were never raised internally.

If you keep discovery fully internal, you save money but inherit a blind spot. People inside the company are too close to the product idea to challenge it properly. An outside facilitator is cheaper to disagree with.

What happens if you skip the discovery phase?

Skipping discovery moves every important decision into the build, where each one costs more to reverse. The result is a longer timeline, a larger budget, and a product that fits the team's assumptions better than your users' needs.

Development teams still produce something without discovery, they just produce it against a moving target. Every new requirement discovered mid-build means a component rebuilt, testing repeated, and documentation updated. Roughly 70% of rework in custom builds traces back to requirements that were never written down or tested during planning. That rework is what discovery prevents.

The other risk is the sunk cost trap. Two months into development, the team realises that the core idea does not match how users actually behave, but the budget is already spent, so the sensible decision is ignored. A good discovery phase tests the riskiest assumptions before large sums are committed. The most important test is whether real users would choose this software over the workaround they already use.

The handover that matters

Discovery ends when the team can present three things in one meeting: the problem, the scope, and the estimate. Present the problem in two sentences, walk through the backlog and the out-of-scope list, then present the estimate and the assumptions behind it. If anyone around the table cannot repeat the problem in their own words, the discovery phase is still open.