Most software projects don't fail because of bad code. They fail because the wrong thing gets built. And by the time everyone realizes it, the budget is spent.
A discovery phase prevents this. It's the two to three weeks at the start of a project where you figure out what to build, for whom, and why — before a single line of code is written. It sounds obvious. Most teams skip it anyway.
What happens when you skip discovery
Here's a pattern I've seen more times than I'd like:
- A company has a clear idea of what they want. They write a brief. Maybe a few pages, maybe a slide deck.
- Development starts immediately. Everyone is excited. Progress is fast.
- Around week six, the first demo happens. The response: "This is what we asked for, but it's not what we meant."
- Three to four weeks of rework follow. New requirements surface. The timeline doubles.
- The final product works, but the budget overran by 40–60%.
The brief was the problem. Not because it was badly written, but because a brief is always incomplete. The people who write it know their business — they don't know software. The people who build the software know code — they don't know the business. Discovery closes that gap.
What a good discovery phase includes
User interviews (not stakeholder interviews)
Talk to the people who will actually use the system, not just the manager who approved the budget. The warehouse employee who packs orders has different needs than the operations director who requested the tool. Both perspectives matter. Most rework comes from building for the director's assumptions instead of the employee's reality.
Workflow mapping
Draw out every step of the current process. Where does data come from? Where does it go? What decisions are made along the way? Where do things break? This usually reveals that the actual workflow is 30% more complex than anyone described in the brief — and that 20% of the described complexity is unnecessary workarounds for limitations that won't exist in a new system.
Scope definition
Based on the workflow mapping, define what goes into v1 and what waits. This is where the hard conversations happen. Everyone wants everything. The discovery phase gives you the evidence to say: "Feature X affects 5% of orders. Let's handle those manually for now and build it into v2 if the volume justifies it."
Technical assessment
What systems need to connect? What data needs to migrate? Are there security or compliance requirements? A two-hour technical review during discovery can prevent a two-week blocker during development. I've seen projects stall for weeks because nobody checked whether the legacy system had an API — turns out it didn't, and the integration approach needed a complete redesign.
Wireframes, not mockups
Rough sketches of key screens. Not pixel-perfect designs — just enough to confirm that the team and the client are picturing the same thing. It's much cheaper to move boxes on a wireframe than to rebuild a frontend.
What discovery costs — and what it saves
A typical discovery phase for a mid-sized business application runs two to three weeks and costs between €2,500 and €5,000. That's 3–5% of a typical project budget.
What it prevents:
- Major rework — One missed requirement caught in week two of discovery would have cost €8,000–€15,000 to fix mid-development
- Scope creep — When the scope is clearly defined upfront, "can we also add..." requests get evaluated against the agreed plan, not bolted on without considering the impact
- Misaligned expectations — The client and the development team are looking at the same wireframes, the same workflow diagrams, the same priority list. There's no room for "this isn't what we meant"
In my experience, projects with a proper discovery phase come in 20–30% closer to the original budget than projects that start coding immediately. On a €50,000 project, that's €10,000–€15,000 saved — a 3x to 5x return on the discovery investment.
When you can skip discovery
Discovery isn't always necessary. You can move faster when:
- The scope is genuinely small — A single-function tool with one user type and no integrations. If you can describe the entire system in five minutes, you probably don't need two weeks of analysis.
- You've built this exact thing before — Not a similar thing. The exact same type of system for a similar business. The patterns are proven and the risks are known.
- It's a v2 of an existing product — You already have real usage data. You know what users need. The discovery was done by the product itself.
For everything else — especially first-time builds, multi-department tools, or systems replacing manual processes — skipping discovery is a false economy.
How to tell if your project needs it
Ask yourself three questions:
- Can I describe exactly what every screen will do, who uses it, and what data flows between them? If the answer involves "we'll figure that out during development," you need discovery.
- Have the actual end users been consulted? If the brief was written by management alone, you need discovery.
- Are there integrations with existing systems? If yes, you need at least a technical assessment.
One "yes" means a lightweight discovery. Two or three means the full process.
Want a second opinion on your project brief?
Send me your project description — however rough or detailed. I'll tell you whether a discovery phase makes sense, what it would cover, and what it would cost for your specific situation. No commitment, no invoice. Just a clear picture of the best next step. Get in touch.