Paid discovery phase software: what to own before you build

The paid discovery phase software vendors put in front of a build is worth buying only if you leave it owning four portable things: a scoped backlog, an architecture proposal, a risk register and an estimate range. If any of those stays locked inside the vendor's tools, you have paid for a longer sales process, not for planning.

The figure most often used to sell discovery, that projects run 45% over budget and deliver 56% less value, comes from McKinsey and Oxford research on IT projects above $15 million, using data as of June 2012. By the end of this post you will know what that study actually supports, what a discovery phase should hand over, why vendors' own price ranges disagree, and which clauses make the output yours to take elsewhere.

The 45% statistic comes from $15 million IT projects in 2012

In October 2012, Michael Bloch, Sven Blumberg and Jürgen Laartz of McKinsey published research run with the University of Oxford. They defined large IT projects as those with initial price tags exceeding $15 million, and found that half of them massively blew their budgets. On average, those projects ran 45% over budget and 7% over time while delivering 56% less value than predicted.

The sample was more than 5,400 projects in the database as of June 2012. The same article found that every additional year on a project increased cost overruns by 15%, and that 17% of IT projects go so badly they can threaten the existence of the company.

Vendor coverage drops the qualifiers. Innowise's discovery guide, dated March 2025, says 45% of large software projects exceed a budget and deliver 56% less value. ClickUp's, dated February 2025, says 45% of large IT projects exceed their budgets. Neither mentions $15 million or 2012, and both turn an average overrun into a share of projects. In the study, the share is half; 45% is the size of the average overrun.

That doesn't make the number useless for a $150,000 build, but it isn't your number. McKinsey's own footnote sends readers to a separate cut of the data covering all IT projects, not only the large ones, published in Harvard Business Review in September 2011. When a proposal quotes 45% at you for a six-month product, ask which projects it was measured on. Asking what happened to projects like yours is reference-class forecasting, the method McKinsey's diagnostic uses to estimate a planned project's true cost and duration.

The strongest case for paying for discovery anyway

The study's lesson isn't "buy discovery". Its recommendations are core practices: rigorous processes for managing requirements engineering and change requests, a few strong stage gates, and a short delivery life cycle. A paid discovery phase is one way to buy the first of those before you've committed the build budget.

McKinsey also describes an organisation whose main obstacle to a well-defined business case was the limited availability of funding during the prestudy phase. Underfunded scoping is a documented failure mode, not a vendor invention. Small budgets aren't immunity either: the HBR piece opens with Levi Strauss, whose IT migration had a proposed budget of less than $5 million and ended with a $192.5 million charge against earnings.

Clean Commit, a studio that charges for discovery, argues that building discovery into a fixed price is a problem for the companies that do it. That holds from your side of the table too. A fixed quote written without discovery prices your uncertainty into the vendor's margin, and you can't see how much of it is margin.

Discovery is the wrong purchase in three cases. When the build is small enough that two weeks of planning is a large slice of it. When you already hold a current SRS and wireframes another team can estimate from. And when the vendor won't let the output leave with you, because then you are paying a deposit on their build and calling it research.

What should a discovery phase deliver?

A discovery phase should deliver documents another team could build from without phoning the first one. Vendors' own lists overlap closely. Acquaint Softtech names a scoped feature list with acceptance criteria, an architecture decision record, user flows and wireframes, a risk register and a cost estimate with explicit assumptions. Clean Commit lists a product roadmap, user flows, user stories with acceptance criteria, a release plan, a recommended tech stack and an optional quote.

The difference between a useful set and a decorative one is whether each item survives a handover. This is the test we would apply to each:

Deliverable	What done looks like	Portability test
Scoped backlog	User stories with acceptance criteria, prioritised, with the first-release line drawn	Exported to a format you control, not only the vendor's project workspace
Architecture proposal	Stack, integrations, data model, and the alternatives rejected with reasons	Depends on no proprietary framework you would have to license from the vendor
Wireframes and user flows	Primary journeys annotated or clickable	Editable source files, not just a PDF or a hosted prototype link
Risk register	Each risk with likelihood, owner and mitigation	Includes risks that cut against the vendor's preferred approach
Estimate range	Low and high figures with every assumption written down	Assumptions specific enough for a second vendor to re-price
Release plan	What ships first and what waits	Tied to backlog items, not to one vendor's team size

The estimate range matters most. Early in a project every estimate is wide, and it narrows only as scope is pinned down; estimators call this the cone of uncertainty. A discovery output with a single number and no assumptions hasn't narrowed anything. It has hidden the width, which will reappear later as change requests.

The scope of work for the build should then reference these documents by version. If you are weighing how a fixed-price or time-and-materials contract carries that remaining width, our post on the clause that fixes both covers the contract that follows discovery.

Can you take discovery output to another vendor?

You can take discovery output to another vendor only if the statement of work says so in writing. Acquaint Softtech's guide says plainly that the pack is yours to use with any vendor; Clean Commit's guide lists what discovery produces but doesn't address who owns it. Treat the first as the standard to ask for, and don't assume it when the proposal is silent.

Five lines in the discovery SOW do most of the work:

• Ownership of every listed deliverable transfers to you on payment of the discovery fee, whether or not you proceed to the build.
• Deliverables arrive in editable formats: backlog export, diagram source, design files, the estimate spreadsheet with its formulas.
• Nothing in the contract restricts you from sharing the output with another vendor for estimation or delivery.
• Each deliverable has acceptance criteria, so "discovery complete" is something you sign off, not something you are told.
• The fee and the end date are fixed, so the phase can't drift into unbilled build work.

Portability also tells you something about the vendor. A team confident in its delivery has no reason to hold the backlog hostage. Our software development company checklist covers the other checks worth running before you sign anything.

How to price the paid discovery phase software vendors propose

Published prices for discovery run from a flat fee of about $3,000 to $30,000 for enterprise work, and durations from one week to two months. The sources don't reconcile, as of November 2026:

Source	Price	Duration
Acquaint Softtech, 27 April 2026	$2,500-$5,000 for an MVP; $6,000-$15,000 for a SaaS platform; $12,000-$30,000 for an enterprise application; framed as 5 to 10% of the development budget	2 weeks; 3-4 weeks; 4-6 weeks
Clean Commit, updated 28 November 2025	Around $3,000 with a new client, refundable if the client hires them	About two weeks short; up to two months long
Innowise, 6 March 2025	No price given	About one or two weeks for a small project; about 4-6 weeks for a larger one

Acquaint's own table doesn't hold to its percentage. Its MVP row pairs a $2,500-$5,000 discovery with a $30,000-$80,000 build, which is anywhere from about 3% to about 17% depending on which ends you match. The enterprise row, $12,000-$30,000 against $150,000-$500,000+, spans roughly 2% to 20%. The percentage is a rule of thumb, not a price.

The same page claims that companies skipping discovery spend 40 to 60% more on development. Acquaint attributes that to its own 1,300+ projects, not to an external study, so treat it as one vendor's experience rather than evidence about your project.

A better sanity check is to price the days, not the percentage. Ask for named roles and days per role. Clean Commit's rough split puts about 50% of discovery time on user stories and acceptance criteria, 15% on estimating and 15% on documentation. If a proposal is mostly workshops and a slide deck, the backlog, which is the part you will actually build from, is underfunded.

Is discovery credited against the build?

Discovery is sometimes credited against the build, and it's worth asking. Clean Commit says its fee is refundable if the client decides to work with us; Acquaint's guide doesn't say either way. A credit lowers the cost of proceeding with the same team.

A credit is also a retention tool: walking away costs you the credit. It's worth having only alongside portability, credited if you proceed and fully yours if you don't. If a vendor offers the credit but restricts reuse of the output, you are looking at a deposit on the build priced as research.

The same logic answers discovery versus a fixed-price quote. A vendor that quotes a fixed price without discovery still does the discovery; it happens after signing, as change requests, which is exactly the process McKinsey says to manage rigorously. A paid phase turns that into a stage gate: at the end you decide to proceed, re-scope or stop, with an estimate range in hand.

Before you sign the discovery statement of work

Check four things. The deliverables list matches the table above. Ownership transfers on payment of the discovery fee. The estimate comes as a range with written assumptions. And the fee is either credited against the build or priced on named roles and days you can verify.

Our own custom software development work runs in the same order: it starts with discovery and requirements definition, then architecture and technical planning, before development begins. For a first product, our MVP development process starts by defining the core problem, target users and the assumptions the MVP needs to validate, and a focused MVP typically takes 6-10 weeks. If you have a discovery proposal on your desk and want to compare it with how we would scope the same build, talk to our custom software development team about the backlog, architecture and estimate range you should walk away with.