Most projects get expensive not while the code is written but because of decisions made before it. What we do in discovery and what you have in hand at the end.
Key takeaways
- Discovery catches the most expensive mistakes at the point where the project is cheapest.
- Its output is not a presentation but a plan with a clear scope, timeline and budget.
- After discovery you can run the project with another team; the outputs are yours.
- The pressure to "just start" is usually the decision that costs the most time later.
In this article5 sections
In a software project the cost of change rises with time. Changing a decision in a meeting takes an hour. Changing the same decision after design is finished takes days, and after launch it takes weeks. Discovery exists to make decisions at the moment they are cheapest.
What discovery is not
Discovery is not bureaucracy that delays the project or a period of writing long documents. With us it usually takes one to two weeks, and at the end you hold not a report to read but a plan to work from.
What do we do in that time?
- We understand the business: we pin down who the product is for, which problem it solves and how success will be measured. Often we find that people inside the team answer these questions differently.
- We map user flows: before drawing screens we run the steps a user will go through on paper. Missing steps and conflicting rules surface here.
- We look for technical risks: systems to integrate with, data sources, legal requirements and performance expectations. You do not want to learn in month three that an integration is not possible.
- We prioritise scope: what goes into the first release, what waits, and why.
What do you have at the end?
At the end of discovery we deliver four things: a prioritised scope list, drafts of the main flows, a technical architecture proposal, and a timeline and budget based on them. These outputs are yours. You can continue the project with us or hand the same plan to another team.
"We already know what we want"
We hear this often, and it is usually true. The team knows what it wants; what is missing is everyone understanding it the same way. Typical discovery findings are two departments expecting different things from the same screen, an approval step nobody owns, or data assumed to come from an existing system that is not actually there. Each of these costs weeks when it is noticed during development.
The price of skipping discovery
Quotes given without discovery end in one of two ways. Either they carry a large safety margin to cover uncertainty, or they look low and the gap is closed with change requests as the project moves on. In both cases your budget pays for what you did not know.
Setting aside a week or two before starting can look like slowing down. Our experience says the opposite: the projects that move fastest are not the ones that start coding on day one, but the ones that start knowing what to write.
