Discovery phase cost in 2026: what to pay and what to refuse

A discovery phase is a paid, fixed-scope engagement that turns an undefined software project into a priced one. You buy three to six weeks of a team's attention. You get back a scope, a technical plan, a prototype, and a number credible enough to put in a budget. In 2026 the market rate sits between $5,000 and $30,000 for most small and mid-size products, or roughly 5% to 10% of the expected build cost.

Here is the buyer's problem. A real discovery and a dressed-up sales call produce the same artifacts: a fixed fee, a few weeks, a document at the end. The difference surfaces four months into the build, when the estimate either holds or doubles. So the useful question before signing goes past the average price. It is what your money has to buy for the price to be defensible.

What does a discovery phase cost in 2026?

Published price guides from software studios in 2026 cluster in a narrow band, and the band tracks project size more closely than studio prestige. Treat these as market rates rather than a standard, because no independent body benchmarks them.

• $5,000 to $12,000. A small product with a clear concept, few integrations, one user type. Two to three weeks.
• $12,000 to $30,000. A mid-market build with several integrations, multiple roles and permissions, real data migration questions. Three to six weeks.
• $40,000 and up. Enterprise or regulated work, where compliance mapping and legacy integration eat most of the calendar.

The percentage rule is the sharper check: discovery generally runs 5% to 10% of the build it prices. On a $180,000 build, a $12,000 discovery is normal. A $2,000 discovery is a sales call with an invoice attached. A $60,000 discovery means you are paying build rates for planning, and somebody has already started building.

Why the "$1 now, $100 later" argument for discovery is wrong

Almost every studio selling discovery reaches for the same justification: a defect caught during requirements costs $1 to fix, the same defect after release costs $100. The curve gets attributed to Barry Boehm and it has been quoted for forty years.

The evidence under it is thin. The original figures trace back to internal IBM training material rather than a peer-reviewed study, and by 2001 Boehm put the ratio closer to 5:1 for small non-critical systems. In 2017, Menzies and colleagues tested the claim against 171 software projects run between 2006 and 2014, the largest study of the effect yet published, and found no evidence for it. The effort to resolve an issue late was not consistently or substantially greater than resolving it soon after it appeared. Their reading: the delayed issue effect turns up intermittently in certain kinds of projects, and it should not be treated as a law of software.

When a studio sells discovery on the strength of that curve, the pitch is running on folklore. The work can still be worth buying. The argument for it has to be better than a number from a 1981 training deck.

The real reason discovery earns its fee

Requirements sit at the center of failed projects, and the evidence there is stronger than the cost curve. PMI's Pulse of the Profession report on requirements management found that 47% of unsuccessful projects miss their goals because of inaccurate requirements management. The Standish Group's CHAOS research places incomplete requirements and specifications at the top of the factors behind challenged projects, at 12.3%, with a clear statement of requirements third among the factors behind successful ones, at 13.0%.

Read what that describes. The failure mode is a team building the wrong thing competently, on time, to spec. Discovery attacks that directly. It forces the decisions that cost an afternoon on paper and a quarter to unwind in a codebase: who this is for, what ships first, what the data model looks like, what is explicitly out of scope.

The second reason is commercial. An undefined project cannot be priced honestly. A studio quoting a fixed price off a two-page brief is either padding the number to cover its own risk, or planning to recover the shortfall through change requests later. Discovery converts guesswork into a scope both sides can be held to. You are buying an estimate you can trust and the option to walk away holding it.

What a discovery phase must produce

Judge the price against the deliverables, never against the calendar. A defensible discovery ships all of these:

• A prioritized scope. Every feature ranked, with the MVP cut marked. Written down, not discussed in a call.
• User flows and wireframes. Screen by screen, how someone gets through the core task. A clickable Figma prototype is the 2026 standard.
• A technical brief. Stack, data model, integration plan, auth approach, hosting. Detailed enough that a different team could read it and act.
• An estimate with ranges. Cost and timeline per milestone, with uncertainty stated per item instead of buried in one contingency percentage.
• Assumptions and exclusions. The list nobody enjoys writing. It is the one that prevents the argument in month four.
• Risks, named. The three things most likely to break the estimate, each with a cost implication attached.

If the output is a findings deck and a single number on the last slide, you paid for a proposal. Proposals are free.

When the price is wrong

Two directions, two different problems.

Too cheap. Under roughly 3% of the build, the fee cannot cover the hours the work takes. Someone is absorbing the difference as sales expense, which means the output serves the sale. A free or near-free discovery is a bid, and bids are written to win rather than to be accurate.

Too expensive. Over roughly 15%, look hard at the deliverables. High-fidelity design of every screen, a working backend, an 80-page requirements document: those are build activities wearing a discovery label. Buying them is fine. Price them as build, and know that you are committing before the estimate exists.

The duration check is simpler. Most discovery lands in three to six weeks, with four weeks the common middle. Past that, either the project is genuinely complex (regulated, legacy integration, many stakeholders), or the discovery has quietly become a project of its own.

What you should not pay for

Some of what gets bundled into a paid discovery is sales work studios have always done for free:

• The first one or two calls, including a rough budget range.
• A capability walkthrough or case study review.
• A written proposal for the discovery itself.
• A high-level read on whether your project is a fit at all.

The line is easy to draw. If the artifact only has value to you once you hire that studio, it is sales. If the artifact keeps its value when you carry it to a different team, it is work, and work gets paid.

A worked example: $12,000 discovery on a $180,000 build

Take a B2B SaaS: multi-tenant, Stripe billing, an admin back office, one third-party integration. Expected build around $180,000, in line with the ranges we see for that scope.

A $12,000 discovery over four weeks is proportionate at 6.7%. For that fee: workshops with the people who actually know the domain, a prioritized backlog with the MVP line drawn through it, a clickable prototype of the four core flows, a technical brief covering the tenancy model and the billing architecture, milestone estimates with ranges, and a risk list where the billing integration and the tenancy decision are named with their cost implications.

Now the test that matters. Hand that package to a second studio and ask them to quote from it. If they return a number close to the first, the discovery did its job: it made the project legible to any competent team. If they come back asking to run a discovery of their own, you bought a sales asset at consulting rates.

That test also answers the fee question. Discovery is worth paying for at the exact point where its output survives the studio that produced it.

Sources

• PMI, Pulse of the Profession: Requirements Management, a Core Competency for Project and Program Success
• Menzies et al., Are delayed issues harder to resolve? Revisiting cost-to-fix of defects throughout the lifecycle, Empirical Software Engineering (2017)
• The Standish Group, CHAOS Report
• What is a software discovery phase, what does it cost, and why skipping it fails