Most software rewrites don't start with bad code. They start with a misread requirement that nobody caught until month three.
The codebase isn't the problem. The problem is that two people — usually the client and the lead engineer — had different mental models of what the product should do. They used the same words. They agreed in the kickoff call. The gap showed up later, after a significant portion of the budget was spent.
A discovery phase is the mechanism that surfaces this gap before any code is written.
What discovery is not
Discovery is not a multi-week workshop exercise with sticky notes and journey maps. It's not a requirements document that nobody reads. It's not a formality inserted into the contract to justify billing another two weeks.
Discovery is the structured work of making ambiguity explicit. It ends with a set of documents clear enough that disagreements about scope surface in writing, not in a retrospective.
What discovery produces
A useful discovery phase produces three things.
A prioritized scope document. Not a feature list — a ranked decision log. For each piece of scope: what does the user need to accomplish, what's the minimum required to accomplish it, and what's optional. The prioritization forces real trade-offs while the cost is still low.
A data model draft. The moment you sketch the core entities and their relationships, false assumptions become visible. The most common discovery finding we encounter: the client thinks user and account are the same entity, and the engineers have been assuming they're separate. That assumption shows up everywhere in the codebase. Catching it in a diagram costs nothing. Catching it after six weeks of API work costs two weeks of rework.
Identified dependencies and unknowns. Third-party integrations that require enterprise contracts. Regulatory constraints nobody mentioned. Existing data that needs to be migrated. Every project has things nobody thought to put in the original brief. Discovery is when you ask the questions that surface them.
A real example
We took on a client mid-project — a marketplace that needed a checkout flow rebuilt. The previous team had shipped roughly twelve weeks of work. The code was reasonable. The problem was that the client needed per-line-item tax calculation because they were selling to both B2B and B2C buyers in different jurisdictions.
Nobody had asked. The previous scope document said "checkout with payment processing." The engineers had built exactly that. The tax requirement invalidated most of the order model they'd built.
Two weeks of discovery at the start would have caught this. The brief would have asked: what types of buyers, what jurisdictions, does tax vary by line item or order total, who handles tax remittance? The answers would have changed the data model before a single migration was written.
Instead, a rebuild.
The business case
Discovery typically costs two to five percent of a project's total budget. The expected value of catching one false assumption that would have caused a partial rewrite is almost always higher than that.
The right way to frame discovery to clients: it's not extra time before the real work starts. It's the mechanism that lets us give you an estimate we'll actually hold to. Projects without discovery get estimates with wide error bars because the estimator is guessing at hidden assumptions. Projects with discovery get tighter estimates because the assumptions have been written down and validated.
Fixed-bid work is only honest after discovery. Before it, any fixed price is an educated guess wearing a confident expression.
How to evaluate a studio on this
Ask any software studio you're considering how they scope a new project. If the answer is "we review your spec and send a proposal," ask what happens when the spec is incomplete. Ask what they do when they discover an assumption was wrong two months in.
The answer tells you whether they've built the workflow to catch problems early, or whether they're relying on the scope document and hoping the ambiguity doesn't surface until after the check clears.
A discovery phase doesn't eliminate surprises. It transforms expensive surprises into cheap ones.