Skipping discovery does not save money; it moves the cost of being wrong from a workshop into a codebase. The question is never whether you pay to understand the problem — only whether you pay early and cheaply or late and dearly.
Discovery is risk retirement
A good discovery phase is not a pile of documents. It is a list of the assumptions the project is betting on, sorted by how much damage each does if it turns out false. The work is to attack the dangerous ones first, while changing your mind still costs a conversation instead of a quarter.
What we actually produce
- A ranked list of risks, each with the cheapest experiment that would settle it.
- A defensible architecture sketch — enough structure to cost and sequence the work.
- The scope we are deliberately not doing yet, written down so it stays cut.
- A first increment small enough to ship and real enough to learn from.
The trap of the tidy plan
A discovery that produces a confident, comprehensive plan is usually hiding its risk rather than exposing it. We would rather end discovery with a shorter plan and a clearer view of what we still do not know. Certainty this early is a warning sign, not a deliverable.
The purpose of discovery is to be wrong on paper, not in production.
How it pays off
Every assumption tested in discovery is a rework cycle avoided in delivery. The phase pays for itself the first time it kills a plausible-sounding feature before a line of code is written for it — and on most engagements it does that more than once.
Buy your surprises early, while they are still cheap.