The Real Cost of Skipping Discovery, in Numbers

There is a moment that comes up often in product development, usually about three months into a build, when someone in the room says "we should have worked this out earlier." By that point the engineers have already written code that will need to be thrown away, the timeline has slipped, and the budget conversation is getting uncomfortable. The thing nobody quite says aloud is that all of it was foreseeable, and most of it was avoidable.

Skipping discovery is rarely a deliberate choice. Teams tell themselves they already understand the problem well enough, or that getting something built quickly is the priority, or that discovery is a luxury they can pick up later. What they are really doing is deferring cost, not avoiding it. The cost does not disappear. It reappears further down the line, wearing a different name: rework, rewrite, scope change, failed launch.

This article is about making that cost visible before it arrives. We are going to walk through what the research says, what we have seen on real projects, and how to put numbers around something that organisations routinely underestimate. If you are building a case for doing discovery properly, or trying to understand why a previous build went over budget, these are the numbers and the patterns worth knowing.

Skipping discovery does not eliminate the cost of getting things wrong. It postpones it, and the interest rate is steep.

The pattern holds whether you are building a consumer app, an internal tool, or a transactional platform. The principles are the same, and so are the failure modes.

What the Research Actually Says About Discovery ROI

The business case for discovery is not hard to make in theory. The difficulty is that the returns are asymmetric and slightly counterintuitive. You spend money earlier, in a phase that produces no visible product, and the payoff arrives later in the form of things that do not go wrong. That is a hard sell in a room full of people who want to see progress.

Forrester Research has modelled what happens when UX is taken seriously across a product, and the conversion rate uplifts projected in their work reach as high as 400% according to Forrester Research's "The Six Steps For Justifying Better UX". That figure captures the optimistic end of the range, but even at a fraction of that, the arithmetic strongly favours investing in understanding users before building for them.

What the research cannot fully capture is the compounding nature of discovery's value. When you understand the problem clearly at the start, every subsequent decision benefits from that clarity. Architecture choices are better. Feature prioritisation is sharper. Onboarding flows are built around real user behaviour rather than internal assumptions. The discovery investment echoes through the entire build, which is why the ROI looks so outsized compared to the cost of the work itself.

Where teams go wrong is treating discovery as a single upstream activity rather than a foundation that holds up everything that follows. The question to ask is not whether you can afford to do discovery. The question is whether you can afford to build without it.

Engineering Rework Rates: The Hidden Budget Drain

Rework is the most tangible cost of skipped discovery, and it is also the most avoidable. When engineers build to a brief that has not been properly validated, a meaningful proportion of what they produce will need to be changed, sometimes completely rewritten, once the real requirements become clear.

We saw this directly on a dating app project where the client chose to invest heavily in onboarding verification and skip discovery for the messaging component entirely. The brief for messaging was generic as a result, and what got built reflected that. The messaging feature allowed automated and fake messages, which directly contradicted the verified, human-only environment the onboarding was designed to create. As Simon put it at the time: "Even though we'd put so much emphasis on the onboarding and validation and verification, that didn't then stack up with the other parts of the product, particularly around the messaging side of things."

The rewrite of that messaging section cost approximately £15,000 in additional budget and added two months to the project timeline. Neither of those costs appeared in the original estimate, because nobody had scoped the feature properly before building it. The engineering hours were real, the delay was real, and all of it traced back to a decision made before a single line of code was written.

Before scoping any feature, check whether it connects to another part of the product that carries a strong design principle. If it does, that feature needs its own discovery, regardless of how simple it looks in isolation.

Rework rates tend to be highest in the parts of a product that teams assume are straightforward. Simple-looking features built on unexamined assumptions are where the hidden costs live.

The Post-Launch Fix Multiplier

Fixing a problem before build begins costs far less than fixing the same problem after launch. This is not a new idea, but the gap between pre-build and post-launch fix costs is wider than most teams instinctively assume, and it grows with the complexity of the system.

Post-launch fixes carry costs that pre-build changes do not. There is the engineering time itself, but there is also regression testing, deployment, user communication if the change is visible, potential app store review cycles, and the reputational cost of users encountering a broken or confusing experience before the fix arrives. In a live product with active users, a broken flow is not an internal inconvenience. It is a conversion problem, a retention problem, and sometimes a trust problem.

The real damage of post-launch fixes is that they arrive at the worst possible moment. A team that has just launched is typically resource-thin, already planning the next phase, and dealing with the normal chaos of a live product. Dropping an expensive rework into that environment creates pressure that reverberates across the whole roadmap.

Post-launch fixes do not just cost money. They cost momentum, and momentum is the one thing an early-stage product cannot easily replace.

What we find, and what every project we have worked on has confirmed in some form, is that the feedback arriving after launch always redirects the product in ways the internal team did not anticipate. Some of that redirection is healthy and expected. But when the redirection is caused by a fundamental misunderstanding of user needs, one that discovery would have surfaced, it is expensive in a way that feels genuinely unnecessary.

Activation Drop-Offs Tied to Skipped Discovery

Activation is the moment a new user completes something that makes the product feel worth keeping. It is the clearest early signal of whether the product is working, and it is one of the first places that skipped discovery shows up in the numbers.

When discovery has been done properly, the onboarding flow is built around real user behaviour. The team knows what people expect to see, what language resonates, what friction feels acceptable and what feels obstructive. When discovery has been skipped, the onboarding is built around what the founding team believes users will do, which is a different thing entirely.

The specific failure modes that drive early abandonment are well-documented from our own work across multiple products. Forced registration before a user has seen any value, too many screens before anything useful happens, permissions asked without explanation, and a value proposition that takes more than a minute to become clear are all patterns that destroy activation rates. Each of them is discoverable before build begins. Each of them is expensive to fix after launch.

Map the emotional state of your user before they open the product, not just what they do once they are inside it. A user arriving in frustration needs a different first screen than one arriving out of curiosity.

The teams who skip discovery and then try to patch activation rates post-launch are doing the right work in the wrong order. Iteration is valuable, but iterating on a fundamentally misunderstood user journey is not the same as refining one that was correctly understood from the start.

The Cost of Partial Discovery

Partial discovery is perhaps the most dangerous version of the problem, because it creates the feeling of having done the work without the protection that comes from doing it thoroughly. A team that ran discovery on three of five components believes it has a solid foundation. The two components it skipped are the ones that will cause problems later.

The dating app project illustrated this precisely. The onboarding had been thoroughly researched and carefully designed. The messaging component had not. From the outside, the product looked considered. Internally, the two halves were working against each other, because the messaging system had been built without understanding what the product was fundamentally trying to do. The rigorously verified onboarding was undermined at every turn by a messaging environment that welcomed exactly the behaviour the onboarding was designed to prevent.

Product coherence requires discovery across all interconnected components. A feature that looks self-contained rarely is. Messaging connects to trust, trust connects to verification, verification connects to the product's core promise. Pull on any one of those threads without understanding the others and the whole thing can unravel.

• Discovery done on onboarding only leaves messaging, notifications, and retention mechanics unvalidated.
• Discovery done on core flows but not edge cases means error states and recovery journeys are built on assumptions.
• Discovery done on desktop but not mobile misses the environment where most users will actually encounter the product.

The question to ask before scoping any discovery phase is which components connect to each other, and which ones have the power to undermine the rest of the product if they are built on a bad assumption.

Scope Creep as a Symptom of Skipped Discovery

Scope creep is almost always treated as a project management problem. In our experience, it is more often a discovery problem. When the real requirements are not understood at the start, they surface progressively during build, and each new requirement adds time, cost, and complexity to a project that was scoped around a simpler version of the problem.

We worked on a grassroots football product where the founders built based on what they believed the product should do rather than what the market was indicating. The team advised against adding complexity and warned clearly that the product was becoming too broad to build and too broad to use. The warnings were not heeded. What should have reached market within three to four months had not launched after twelve to fourteen months of development. The budget almost doubled over the course of the project. Simon's summary of it was direct: "All of which we advised was going to happen."

Scope creep of that scale does not usually happen because a team changes its mind. It happens because the team did not have a clear enough picture of the problem at the start. Each new feature that gets added mid-build is, in some sense, a piece of discovery that should have happened earlier, now being done at the most expensive possible moment.

When a stakeholder requests a new feature mid-build, ask what problem it solves and whether that problem was visible before the project started. If the answer to the second question is yes, it is a discovery gap, not a new requirement.

A clean scope built on thorough discovery is not a constraint on creativity. It is the thing that gives a team permission to build confidently, knowing the decisions were grounded in something real.

What Discovery Actually Costs Versus What Skipping It Costs

The Real Comparison

Discovery is typically a fraction of total build cost. Depending on the scale and complexity of the product, a thorough discovery phase runs somewhere between five and fifteen percent of the overall project budget. For a product costing £100,000 to build, that is somewhere between £5,000 and £15,000. That is not a trivial number, but it is a tractable one, and it is a fixed cost paid upfront rather than an unpredictable cost paid later.

The costs of skipping it are harder to predict in advance, which is partly why teams underestimate them. The £15,000 messaging rewrite on the dating app project was not anticipated in the original budget. The near-doubling of spend on the football app was not anticipated either. These are not exceptional outcomes. They are the normal consequence of building without a clear foundation.

Framing It as Insurance

One way to think about discovery investment is as insurance against the specific failure modes we know skipped discovery produces. Rework, post-launch fixes, activation failures, and scope creep all have predictable cost ranges. Discovery reduces the probability of each of them materialising. The expected value of that reduction is almost always higher than the cost of the discovery itself.

Getting something imperfect to market quickly and iterating is genuinely cheaper and more effective than attempting to build the perfect product from the start. That philosophy is sound, but it only works if the thing you launch is built on a real understanding of the problem. Shipping fast on a bad assumption is not iteration. It is just fast failure.

How to Present These Numbers to a Board

Boards tend to respond to discovery as a cost item rather than a risk-reduction mechanism, which is why the conversation about it so often goes badly. The team asks for budget to do something that produces no visible output, and the board sees an opportunity to save money. Reframing discovery as a financial control rather than a creative exercise changes the dynamic significantly.

The most effective approach is to translate the known failure modes into projected costs, then compare those projections to the cost of discovery. If your engineering day rate is £600 and a single rework cycle takes three weeks, that is around £63,000 before you account for delays to adjacent workstreams. A discovery phase that costs £8,000 and meaningfully reduces the probability of that rework cycle is not an optional expense. The arithmetic is clear.

The second move is to be specific about what discovery prevents, not just what it produces. A discovery phase does not just generate research outputs. It validates assumptions before they are built into production code, reduces the likelihood of post-launch fixes, gives the engineering team a clearer brief, and makes scope changes less likely during build. Each of those outcomes has a financial value that a board can engage with.

Where you have real project data, use it. The football app that spent twelve to fourteen months in development and never launched, with a budget that nearly doubled, is a more compelling argument than any generic statistic. Real numbers from real projects carry a weight that research averages do not.

Present discovery as the decision that makes everything else cost what it is supposed to cost.

Conclusion

The financial case for discovery is not complicated. The money that gets spent on rework, post-launch fixes, scope changes, and failed launches consistently exceeds the money that would have been spent on understanding the problem properly before building. That gap is not theoretical. We have measured it on specific projects, and the pattern holds.

What makes discovery hard to fund is not the logic but the timing. You pay for it before you have anything to show, and you save money on problems that never materialise, which means the saving is invisible. The team that avoided a £15,000 messaging rewrite by doing discovery properly has nothing to point to. The team that skipped discovery and paid £15,000 for the rewrite has a very clear lesson to share.

The answer is to build the case before the problem arrives, using the failure modes we know and the cost patterns we can document. Discovery done well does not just reduce the chance of things going wrong. It changes the quality of every decision that follows from it, because those decisions are made with real information rather than assumptions.

After every product launch we have worked on, user feedback has taken the product somewhere the internal team did not fully anticipate. That is not a failure of planning. It is the nature of building for real people. Discovery does not eliminate that uncertainty, but it closes the gap significantly, and closing that gap is almost always the cheapest thing a team can do.

If you are at the start of a build and trying to work out whether discovery is worth the investment, or if you are mid-project and starting to see the signs of skipped discovery showing up in your budget, let's talk about your project.

Frequently Asked Questions