The Discovery Phase Nobody Wants to Pay For

“Can we just start building?”

It’s the most common request we hear from clients. They have an idea. They have a deadline. They have budget. What they want is code. What they need, before any code is written, is a specification.

But specifications aren’t exciting. They’re not a demo you can show to stakeholders. They’re not a pull request you can merge. They feel like overhead, time and money spent before the “real work” starts.

So teams skip it. Or they rush through it with a few meetings and a slide deck. Then they start building. And then, three months in, they discover that the feature they’ve been building doesn’t actually solve the problem. Or it solves the wrong problem. Or it solves the right problem in a way that can’t scale, can’t integrate, or doesn’t account for a constraint that everyone assumed someone else was tracking.

The discovery phase exists to prevent exactly this. And it’s the phase that nobody wants to pay for.

The economics of change

There’s a well-documented cost curve in software development: the later a problem is discovered, the more expensive it is to fix.

A requirement misunderstanding caught during discovery costs a conversation. The same misunderstanding caught during development costs a refactor. Caught during testing, it costs a sprint. Caught in production, it costs an incident, a patch, a deployment, and the trust of whoever was affected.

The ratios vary depending on the study, but the pattern is consistent: fixing a problem found in requirements is roughly 10 to 100 times cheaper than fixing the same problem found in production. This isn’t a new insight. Barry Boehm documented it in the 1980s. It’s been confirmed repeatedly since. And teams continue to skip the phase where problems are cheapest to find.

The reason is simple: the cost of discovery is visible and immediate. The cost of skipping it is hidden and deferred. When you’re deciding how to allocate a limited budget, the visible cost always feels harder to justify than the hypothetical future savings.

This is a mistake. But it’s a rational mistake, which is why it keeps happening.

Discovery is specification work

Let’s be specific about what discovery actually produces.

It’s not a requirements document that gets filed away. It’s not a set of user stories that describe the happy path. It’s the systematic process of defining what the software should do, in enough detail that an engineer can implement it, a tester can verify it, and a stakeholder can confirm it’s correct.

That’s specification work.

Discovery asks: What are the inputs? What are the outputs? What happens when the input is invalid? What happens when the system is under load? What are the security constraints? What integrations are required? What data formats are expected? What happens when a dependency is unavailable? What business rules govern the logic? Are there edge cases that the business handles manually today?

Each answer becomes a clause in the specification. Each clause is a verifiable assertion that the implementation can be tested against. The discovery phase doesn’t produce a document that gets forgotten. It produces the specification that drives the entire project.

What gets skipped

When teams rush through discovery, the same categories of knowledge get missed every time.

Edge cases. The business has been handling them manually for years. The people who handle them know the rules intuitively but have never written them down. If nobody interviews those people during discovery, the software won’t handle the edge cases either, and the team will find out when a customer complains.

Integration constraints. The new system has to talk to the old system. The old system has an API, but it has undocumented rate limits, a quirky authentication flow, and a data format that doesn’t match the new system’s schema. If nobody maps these constraints during discovery, the team discovers them during integration, the most expensive possible time.

Non-functional requirements. Performance targets, availability requirements, compliance obligations, accessibility standards. These are rarely mentioned in the initial brief because the client assumes they’re obvious. They’re not. And they fundamentally shape the architecture. Discovering a 99.9% uptime requirement after you’ve built on a single-server architecture is not a conversation anyone wants to have.

Organizational constraints. Who needs to approve changes? What deployment process exists? Are there change windows? Are there compliance review requirements? These aren’t technical questions, but they determine how the software gets built and shipped. Missing them means building something that can’t actually be deployed into the client’s environment.

Every one of these is discoverable. None of them are discoverable from a slide deck. They require conversations, diagramming, prototyping, and time, the things that discovery provides.

Speed through clarity

Teams that invest in discovery ship faster, not slower.

It seems paradoxical. How can spending more time before building lead to faster delivery? Because the time you spend in discovery displaces a much larger amount of time that would otherwise be spent on rework, miscommunication, and mid-project pivots.

A well-specified project has fewer surprises. Engineers know what to build. Testers know what to test. Stakeholders know what to expect. Decisions that would otherwise require three rounds of Slack threads and a meeting are already resolved. The specification is the single source of truth, and everyone can reference it instead of relitigating the same questions.

Projects that skip discovery feel faster at the start. Code is being written from day one. But the velocity is an illusion. Three weeks in, the team discovers a fundamental misunderstanding. Two sprints of work get scrapped. The architecture needs to change. The timeline slips. The budget increases. And the cost of that rework far exceeds what discovery would have cost.

From phase to infrastructure

The traditional view of discovery is that it’s a phase: a bounded period at the beginning of a project that produces a set of requirements. Once it’s done, you move to design, then implementation, then testing.

This model is better than skipping discovery entirely, but it still treats the output as a one-time artifact. The requirements document gets written, reviewed, and filed. By the time implementation starts, it’s already beginning to drift.

A spec-first approach changes this. Discovery doesn’t produce a document. It produces specifications. Those specifications are living artifacts that evolve with the project. They get implemented, validated, and locked. They get updated when requirements change. They persist as the authoritative record of what the software does and why.

In this model, discovery isn’t a phase you complete and forget. It’s the beginning of the specification layer that the entire project is built on. The work you do in discovery becomes the infrastructure that accelerates everything that follows.

The conversation we keep having

We have this conversation with almost every client. They want to move fast. They have pressure from stakeholders, investors, or deadlines. They see discovery as a speed bump.

And we get it. The pressure is real. The budget is real. The deadline is real.

But we’ve seen what happens on both sides. We’ve seen projects that invested in discovery ship on time and on budget, because the team knew what they were building and built it right the first time. And we’ve seen projects that skipped discovery blow past their deadline and budget, because the team spent months building the wrong thing before they built the right thing.

Discovery isn’t the cost. It’s the investment that reduces every other cost. The teams that understand this build better software faster. The ones that don’t pay for it eventually, they just pay more, later, and in pain.