The Real Cost of Skipping a Discovery Sprint

1. The artifact: three quotes, three different products

Send the same brief to three development teams and the quotes come back R 400,000, R 950,000 and R 2.1 million.

Most founders read that spread as a market signal. Someone is greedy, someone is desperate, and the truth sits in the middle. That reading is wrong, and it is expensive, because those are three prices for three different products.

The brief did not constrain what gets built, so each team filled the gaps privately, from experience and self-interest, and priced what they imagined. One assumed a single user role. One assumed an admin portal, because products like this grow one eventually. One assumed the compliance requirements were real and staffed for them. None of them wrote those assumptions down, because none of them were asked to.

You now have a comparison you cannot use. The information worth having in it is the variance: a 400% spread measures how much of your product remained undecided at the moment you asked someone to price it.

Most founders have that artifact sitting in an inbox already.

2. You cannot skip discovery. You can only relocate it

Discovery is not a phase. It is a set of questions that have to be answered before software can exist: who this is for, what happens when they do the thing, who can see what, what the system does when the payment fails, what “done” means for the first release. Those questions all get answered before launch, because a working product is one where somebody has answered them.

The only variable is the medium you answer them in.

You can answer them in a document, where an answer costs a conversation and changing it costs a different conversation. Or you can answer them in code, where an answer costs a sprint and changing it costs a refactor, a data migration, and a conversation about the timeline that nobody enjoys.

Skipping discovery feels like removing a cost. It works more like a currency conversion, done at a punitive rate, with nobody announcing the exchange.

It also happens by default rather than by decision. You do not sit in a kickoff and agree to resolve the permissions model in production. The build starts, the question surfaces in week six because a developer is blocked and needs an answer that morning, and someone gives it in ten minutes on a call. That answer is now in the schema. A product decision got made under time pressure by whoever was available, and it will shape the next eighteen months.

The team was not careless and neither were you. A build that starts before the questions are finished pulls the answers out of whoever is nearest, in whatever order the code happens to need them.

3. Where the bill lands

The relocated discovery shows up in four predictable places. None of them arrive labelled as the cost of skipping discovery, which is why few founders trace them back to it.

As rework that looks like normal iteration. The team builds the flow, you see it, and it is not what you meant. You both treat this as healthy agile feedback, and sometimes it is. But “I have seen it and I want it slightly different” and “I have seen it and this is the wrong thing” are different events, and the second is a discovery question answered three months late at build prices. The tell is whether the change touches the screen or the data model underneath it.

As scope arguments that are definition arguments underneath. Halfway through, you and the team disagree about whether something is included. It presents as a commercial dispute. Underneath, the two of you have discovered that a word in the brief meant different things to each of you, and nothing forced anyone to define it while defining it was still cheap.

As architecture that quietly hardens around a guess. The most expensive category, and the quietest. An assumption made in week two about tenancy, roles, data ownership, or offline behaviour becomes load-bearing by week ten. No one flagged it, because at the time it was a default rather than a decision. Reversing it in week ten means rebuilding the part everything else sits on. We wrote about this failure mode from the other end in Vibe Coding 16 Weeks Later: the architecture you did not choose on purpose is still your architecture.

As a launch into an audience you never confirmed. The failure that no amount of engineering discipline catches, because the software is fine. The product works and nobody needs it. Here the cost is the whole budget rather than a percentage of it, and it is the one failure discovery is good at preventing, because planning is the last stage where “do not build this” is still on the table.

The first three are recoverable and painful. The fourth is neither, which is why the honest version of this work has to include a real willingness to tell someone not to proceed. A team that cannot produce that answer is running sales with a discovery-shaped invoice.

4. What the numbers say

The strongest evidence comes from McKinsey and the University of Oxford’s study of more than 5,400 IT projects: on average, large IT projects ran 45% over budget, 7% over time, and delivered 56% less value than predicted. The value number is the one that gets quoted least and matters most. Overspending by 45% is a budget problem. Delivering 56% less value than predicted is a discovery problem, because predicted and delivered value diverge when different people understood the thing being built differently.

That study looked at projects with budgets above 15 million US dollars, which is not your app. But the cause it identifies is definition failure rather than headcount, and definition failure does not need scale to happen. A four-person build can misunderstand its own scope as badly as a four-hundred-person one, and it has far less slack to absorb the correction.

NIST’s work on the economics of software testing puts a number on the shape of that cost: a defect caught in production can cost up to 100 times what the same defect costs in the design phase. Defects and product decisions are different things, but they decay the same way. Both are cheap while they are still ideas and expensive once code depends on them.

5. When building first is the right call

Left unqualified, the argument above proves too much, so it needs a limit.

Some questions cannot be answered in a document. “Does this interaction feel right” is one. “Will this integration behave the way the vendor’s documentation claims” is another, and that documentation is wrong often enough to make the assumption naive. For questions in that family, building is the discovery, and it is the cheapest method available, because a document about whether something feels good is worth close to nothing.

That is what a prototype is for, and it earns its cost when you aim it at a named unknown.

The distinction is which unknown you are chasing:

• If the open question is “how should this feel”, build a prototype. A document cannot answer it.
• If the open question is “what should exist, and for whom, and what happens at the edges”, resolve it on paper. Code is an expensive way to have that conversation, and it commits you while you are having it.

Building early is not the failure. Building early without knowing which question you are answering is, because a prototype aimed at a feel question then becomes the foundation for a scope no one agreed to. No one announces that transition from prototype to accidental architecture. It is the same drift covered in Working Code Isn’t Production-Ready Code, arriving from the product side rather than the engineering side.

6. Why competent people skip it anyway

Founders who skip discovery are rarely being reckless, and pretending otherwise makes for a weak argument. There are three real reasons, and two of them are good.

The first is momentum, and it is a real cost. Two weeks of planning is two weeks of not shipping, and for a product whose main risk is being late, that trade is real. Sometimes speed is the correct priority. The honest response is that this holds when you know what you are building and the risk is execution. When the risk is definition, moving fast in an unknown direction is not speed.

The second is that discovery theatre exists, and people have been burned by it. A month of workshops, a facilitator, sticky notes, a sixty-slide deck, a shared understanding that evaporates on contact with the first technical constraint, and an invoice. If that is what someone means by discovery, skipping it is correct. The defence is to be specific about what separates the two. Real discovery is run by the people who would have to build the thing, produces a document precise enough to price, and can return the answer “do not build this.” Workshop discovery run by strategists who never carry the consequences produces alignment, which feels like progress and constrains nothing.

The third reason is the uncomfortable one. Discovery can return an answer you do not want. A founder who has told investors and their family that this is the thing has an incentive not to commission a rigorous check on whether it is the thing. Few founders say this out loud, and it explains a fair number of the rushes past planning toward a build the founder approved in their own head months ago. Of the three reasons, it is the only one that collapses the moment you examine it.

7. The test worth running this week

You do not need to buy anything to find out whether you have a definition problem. Three checks, all free.

Check the quote spread. If you have quotes from multiple teams and they vary by more than roughly 50%, the teams are pricing different products. Your brief did not constrain what they were pricing. If they came back within 20% of each other, your specification is doing real work.

Write the first release down separately. Take everyone who believes they already know the plan, your co-founder, your lead developer, whoever has to sell it, and have each person write down what ships in the first release. Twenty minutes, no conferring. Then compare the lists. Anything that appears on one list and not the others was never decided, it was assumed by one person and filled in differently by the rest. Each of those is a scope argument scheduled for week nine, and you can have it now for the price of an afternoon.

Name who operates it. Not who uses it. Who runs it: refunds, disputes, moderation, support, the person who has to fix a booking at 11pm. Briefs describe what users do. Operators shape the product more than users do, and admin tooling is the most reliable source of unplanned scope in a build, because it never appears in the deck.

Fail any of these and the discovery is still ahead of you. The only remaining question is whether you do it deliberately, at document prices, while the answers are still reversible, or in six weeks, in code, one blocked developer at a time.

Both paths cost money. Only one of them can still end with you deciding not to build.