Do you need a discovery phase

What a discovery phase actually is

Strip the packaging off and a discovery phase is a short paid engagement whose deliverable is decisions rather than software. You pay a firm for two to four weeks. At the end you hold a written description of what is going to be built, in enough detail that someone can price it and someone else can disagree with it. Nothing is in production. That is not a defect; it is the definition.

The reason it exists is that estimates are worthless without knowledge, and knowledge costs money to acquire. A firm that quotes a six-month build for a system touching four of your internal tools, having seen none of them, is not estimating. It is guessing and adding a margin for being wrong, and you pay that margin either way — as a padded fixed price, or as a change order in month four.

The honest version of the pitch is: spend a little now to make the large number predictable. That is sometimes true. The question is when.

The one question

Here it is. Is there an unknown in this project that would change the plan if the answer went the other way?

Not an unknown that would change the schedule. Not one that would make the work harder. One that would change what you build, or whether you build it at all. If you can name that unknown in a sentence, discovery is probably worth buying, and the discovery should be aimed at that sentence and nothing else. If you cannot name one — if you know what the thing is, you know where the data lives, you have done something like it before — then what you want is not discovery. It is a scope and a price.

The test has a second half, which is arithmetic. Discovery is worth its price when the cost of being wrong exceeds the cost of finding out. A four-week discovery at $30,000 in front of a $200,000 build spends 15% to protect the other 85% — usually a good trade. The same discovery in front of a $60,000 build is half the project, and you would do better to start the build with a two-week checkpoint and a right to walk.

Three kinds of unknown, and only two of them are ours

Most projects that stall carry one of three unknowns. They are not equally suited to being resolved by an outside firm, and confusing them is the most common way discovery money gets wasted.

The requirement unknown. Who uses this, what do they do today, what decision does the software change, what happens when they refuse to use it. This is knowledge about your own business. An outside firm can run the conversation and write the answers down cleanly — a neutral party gets straighter answers out of two departments who disagree than either gets out of the other. But nobody discovers your operations faster than the person who runs them. If your discovery is mostly interviews with your own staff, you are paying consultant rates to hold a meeting you could have held.

The data unknown. Does the data that has to exist actually exist, at the quality and history the idea assumes. This is the one that kills projects, and it is genuinely hard to answer from the outside without doing the work. Anyone can tell you the table exists. Finding out that the field everyone relies on has been populated by hand since 2023, is blank for one region, and changed meaning after a system migration, requires someone to sit with the real rows for a week.

The integration unknown. Can we get data out of this system and results back into it, in the time available, with credentials someone will actually grant. This is boring, and it is where schedules go to die. A vendor API limited to two calls per second reshapes an entire architecture — an afternoon to find out, six weeks to discover the hard way.

What you are unsure about	Can a short paid discovery resolve it?	Better move
Whether the data supports the idea	Yes, and this is the strongest case for buying one	Two to three weeks, hands on your real data, with a written go or no-go
Whether a system can be integrated in time	Yes — usually in days, not weeks	A narrow technical spike, priced as a spike, not a phase
What the software should do	Partly. The firm can structure it; the answers are yours	Write the one-page version yourself first, then pay for the critique
Whether the vendor is any good	Yes, and it is an underrated reason to buy one	Treat discovery as a paid audition with a clean exit
Whether the project is worth doing	Rarely. That is a business case, not a technical finding	Do the baseline arithmetic in a spreadsheet first
How much it will cost	Only if the unknowns above are the reason you cannot price it	Ask two firms for a range with assumptions listed, free

When you do not need one

There are more of these cases than the industry likes to admit.

You are replacing something that already works. If there is a spreadsheet, a manual process, or an old application doing the job today, the requirements are visible. Watch someone do it for two hours, record the steps, and you have most of what a discovery would produce. The existing thing is the specification.

The scope is small. Below roughly $75,000 of build, the discovery overhead eats the benefit. Start the work, keep the first checkpoint at two weeks, and make sure the contract lets either side stop there without penalty.

The firm has built this exact shape before. Not this industry — this shape: a document extraction pipeline, an internal approval tool, a warehouse and a reporting layer. A firm on its ninth version of something can price it without studying you. Ask whether the discovery is for their benefit or yours, and listen to how quickly the answer comes.

You already wrote it down. If you have a document naming the users, the systems, the data, the decision the software changes, and what you would count as success, send that document and ask for a price. A firm that insists on a paid phase to reproduce a document you already handed them is telling you something.

The unknown is legal, political or organizational. If the real blocker is that two department heads want different things, or your legal team has not decided what may leave your network, no amount of engineering discovery moves it. That work is internal and it is free, in the sense that no invoice will make it happen faster.

What the deliverable has to contain

This is the part to negotiate before you sign, because a discovery with vague deliverables reliably produces a slide deck. Name the artifacts in the agreement.

A written scope, in prose, that a skeptical person could argue with. Not bullet points of themes. Sentences that say what the system does, in what order, for whom, with what left out. The section listing what is deliberately excluded is the one that prevents the argument in month three.

The named unknowns, and what was found. If discovery was bought to answer three questions, the document says what the three questions were and what the answers turned out to be, including the ones that came back inconvenient. A discovery report where everything worked out is a sales document.

Something that ran. This is the line we would hold hardest. At least one piece of real code must have touched a real system with real credentials against real data — a script that pulled a thousand rows, a call to the vendor API that proved the rate limit, a rough model run against last quarter's records. A discovery with no code in it is a set of opinions about your project. The spike is what turns opinion into fact, and it usually takes two days out of the three weeks.

An architecture that fits on one page. Boxes and arrows, the real system names, where the data sits, what is bought versus built. If it needs six pages at this stage, the thinking is not finished.

A sized plan with ranges and the assumptions written next to them. Not a single number. A range, and the specific assumption that would break each one. “Twelve to sixteen weeks, assuming the vendor grants a sandbox credential within ten business days; add three weeks if not.” That sentence is worth more than the estimate itself, because it tells you which risks you can go retire yourself, today, for free.

An explicit stop recommendation. The document should contain the sentence “we recommend proceeding” or “we recommend not proceeding, for these reasons.” A firm that cannot write the second sentence has never written it, and you should assume you are reading the first one by default.

Time and money, honestly

Ranges vary by market, team size and how much of your organization has to be interviewed, but the shape is consistent enough to be useful.

Shape	Duration	Typical range	What you should get
Technical spike	3–5 days	$5,000–$15,000	One question answered with running code — can we integrate, is the data there
Focused discovery	2–3 weeks	$15,000–$40,000	Scope, architecture, sized plan, one working spike, go or no-go
Full discovery with process work	4–6 weeks	$40,000–$90,000	The above plus current-state process mapping across several teams

Two rules of thumb hold up. Discovery should land between 5% and 15% of the expected build. And a discovery running past four weeks with no code written in it has become consulting, which is a different purchase with a different value — sometimes the right one, but you should know which one you are making.

Two commercial terms are worth asking for, and reasonable firms say yes to both. Credit against the build: some or all of the discovery fee applies to the project if you proceed. Half is common and fair. No obligation: you may take the deliverable to another firm, or to your own team, and build it there. If the deliverable is only usable by the firm that wrote it, it was not a scope. It was a proposal.

How discovery goes wrong

• No code is written — the output is a set of confident opinions nobody tested against a real system
• It becomes a requirements-gathering marathon across nine stakeholders, none of whom can approve anything
• The deliverable is a deck, so the reasoning is invisible and cannot be argued with
• The scope is written to be un-buildable by anyone else, which makes it a proposal in a scope's clothing
• The estimate is a single number with no ranges and no assumptions attached to it
• The team that does discovery is not the team that would do the build, so the knowledge evaporates on handover
• It answers questions nobody asked while leaving the one unknown that started this untouched
• There is no path to “stop” in the design of the engagement, so the recommendation was decided before it began

The handover point deserves emphasis. Ask in writing which named people from the discovery will be on the build. In a small firm it is usually the same two people and costs nothing to confirm. In a large one, discovery and delivery are often different populations at different rates, and much of what was learned lives in heads moving to the next account.

The cheaper things to try first

Before buying anything, three moves cost nothing and often make the purchase unnecessary.

Write one page yourself. What we want, who uses it, what systems it touches, what we would count as working, what we are not doing. It takes an afternoon. Send it to two firms. The quality of the questions that come back is the most informative free signal available to you, and it separates firms that listen from firms that pitch.

Do the baseline arithmetic. How many times a week does this happen, how long does it take, what does an hour cost you, what is the error rate now. If the annual value turns out to be $40,000, you have saved yourself the whole conversation. This number is also what any pilot will later be measured against, so it is work you will need eventually.

Ask for the assumptions instead of the estimate. “What would you need to know to price this, and what would you assume if you answered today?” A good firm sends a short list. Half of it is things you can find out yourself this week, for free — which is exactly what you were about to pay for.

Before you sign a discovery

• You can name the unknown in one sentence, and the engagement is aimed at it
• The fee is between 5% and 15% of the expected build
• At least one working spike against real data or a real system is a named deliverable
• The written scope includes what is deliberately excluded
• The estimate comes as ranges with the breaking assumption next to each
• A “do not proceed” recommendation is a permitted outcome, stated in the agreement
• You own the deliverable and may build it with anyone
• Some or all of the fee credits against the build
• The named people doing discovery are the named people doing the build
• It ends on a date, and that date is under four weeks

Bottom line

Buy discovery when there is a real unknown that would change the plan, when the unknown is technical rather than political, and when the build is large enough that 10% is cheap insurance. Refuse it when you are replacing something visible, when the project is small, when the firm has built the same shape nine times, or when you already wrote the document they are proposing to write. And whatever you buy, insist that something ran. The value in a discovery is not the document; it is the two days somebody spent inside your actual data, finding the thing that would otherwise have surfaced in month four.

Frequently asked questions