What a discovery phase delivers (and what it should not)

A discovery phase is a short, fixed block of research at the start of a software project that turns a rough idea into a scoped, costed, buildable plan. It runs before any production code. Its job is to replace assumptions with decisions: what gets built, for whom, in what order, at what price range, and what is deliberately left out.

Founders reach for a discovery phase when the idea is clear in their head but not on paper, when two vendors quote wildly different numbers for the same brief, or when an internal team relitigates scope in every meeting. The output is a set of documents and a prototype concrete enough that a second team could pick them up and build from them. Here is what a discovery phase produces, what it costs, and the four things it should never pretend to be.

The 30-second version

A discovery phase usually lasts one to six weeks and costs 10 to 15 percent of the total project budget. It produces a scope document, user stories, a stakeholder map, an architecture direction, low-fidelity prototypes, and a roadmap with a cost estimate. It exists because unclear requirements are the largest single cause of software projects failing. It does not lock a final price, it does not replace building, and it stops adding value once you have enough clarity to start.

Why discovery exists

Most software projects do not fail on code quality. They fail on requirements. The Standish Group's failure analysis puts unclear requirements at the top of the causes, ahead of scope creep and inadequate planning. The Project Management Institute reports the same shape: inaccurate or poorly managed requirements sit behind roughly four in ten failed projects. Industry reviews estimate that about half of all rework in a build traces back to requirements that were never gathered properly in the first place.

Discovery is the cheapest place to be wrong. Changing a decision in a document costs an email. Changing the same decision after three sprints of code costs weeks. That gap is the entire economic case for the phase, and it is why skipping discovery on anything non-trivial tends to cost more than running it.

How a discovery phase runs

The work is part interview, part workshop, part technical probe. It starts with sessions that pull the real goal out of the founder's head and onto a shared board: the problem, the users, the money model, the constraints. From there the team runs a handful of focused activities. Requirements workshops turn goals into scoped features. A technical spike tests the risky integration or the unproven assumption before it is priced. Quick user or stakeholder interviews check that the problem is the one worth solving. Each activity ends in one of the deliverables below, which is how you tell a real discovery from a series of meetings: every session produces an artifact someone can act on.

What a discovery phase actually delivers

A serious discovery phase produces artifacts, not slides. The exact set varies by project, but six deliverables show up on almost every engagement:

• A scope document. The single reference for what is in, what is explicitly out, and why. Every later argument about "was that included?" gets settled here.
• User stories and use cases. Functionality described from the user's point of view, detailed enough to estimate and to test against later.
• A stakeholder map. Who decides, who signs off, who needs to be consulted, and how each one wants to be kept in the loop.
• An architecture direction. The main technical choices (stack, data model, integrations, hosting) with the trade-offs written down, not the full system design.
• Low-fidelity prototypes. Clickable enough to catch flow problems before they become code, not polished enough to mistake for the product.
• A roadmap with an estimate. A phased plan and a cost range tied to explicit assumptions, so the number moves only when the assumptions do.

How long it takes and what it costs

Duration tracks complexity. A simple internal tool or a tight MVP fits in one to two weeks. Most business software lands at two to four weeks. Enterprise systems, AI features, or heavy compliance push it to four to eight. Four weeks is the common balance between speed and depth.

Cost usually runs 10 to 15 percent of the build budget. In concrete terms, an MVP with a 50,000 dollar build budget carries roughly 2,500 to 5,000 dollars of discovery; a full SaaS platform around 150,000 dollars runs 8,000 to 15,000. Providers that sell discovery estimate that spending 5 to 10 percent of budget on it cuts development overspend by 40 to 60 percent. Treat that as a directional claim from an interested party, not a law. The direction, though, matches the requirements-failure data: the earlier you catch a wrong assumption, the less it costs.

Picture a two-founder team that arrives with "a marketplace for X". Four weeks of discovery can turn that into a set of scoped user stories, a decision to launch one side of the marketplace first, a payment integration flagged as the main technical risk, and an estimate with a plus-or-minus band tied to one open question: whether in-app messaging ships at launch. That single question might be a three-week swing in the timeline. Finding it in a document instead of in sprint six is the point of the phase.

Four things discovery should not pretend to be

The phase earns trust by being honest about its edges.

1. A fixed final price. Discovery produces a range and a list of assumptions, not a contract number. Anyone quoting a precise total for an unbuilt product is pricing on faith.
2. A substitute for building. A clickable prototype is a communication tool. It has no real data, no edge cases, and no production hardening. Mistaking it for the product is how timelines slip.
3. A place to design every screen. Pixel-perfect UI for the whole app and a fully written backlog belong to delivery. Paying discovery rates to produce them is expensive and premature.
4. A search for certainty. Past roughly eight weeks, discovery usually tips into analysis paralysis. The goal is enough clarity to move with confidence, not perfect knowledge you will never reach.

One more, quietly: discovery should not be a sales pitch in a lab coat. A discovery that can only ever conclude "yes, hire us for the full build" was never research. A real one is allowed to end with "build a smaller version first", or "this does not need custom software at all".

When you can skip it

Skip a formal discovery phase when the scope is genuinely small and well understood: a landing page, a single integration, a change to a system you already run. For anything multi-tenant, regulated, or longer than a few weeks, skipping discovery is usually where the overspend starts.

Where discovery sits next to cost and hiring

Discovery is the first line item in a build budget, so it reads well alongside what a discovery phase should and should not cost and the wider question of what it costs to build a SaaS in 2026. If you are running discovery to compare vendors, the six deliverables above double as the scorecard for a fair comparison: every serious bidder should hand back the same artifacts.

Sources

• PMI: Poor requirements management as a source of failed projects
• TechMagic: The discovery phase in software development
• Agilie: Project discovery phase guide
• SolveIT: Discovery phase steps, deliverables, and costs
• Softermii: Discovery phase steps, deliverables, benefits