Do you need a discovery phase before you start building?
A discovery phase is worth the money when requirements are unclear, the technology uncertain, or the investment large – it produces a target picture, a solution sketch, a risk map, and a cost range before the build starts. For a small, familiar assignment, it can just delay things. A reasonable cost is a few percent of the project.
A discovery phase can be the best-invested part of a project – or a way to delay decisions and burn budget before a single line of code is written. The difference lies in the uncertainty. The more unclear the assignment, the more clarity is worth. The more familiar it is, the more the discovery phase becomes a detour.
What a good discovery phase actually delivers
A discovery phase worth the name ends in a decision-ready document, not a polished slide deck. Four things need to be in place:
- Target picture. What problem does the product solve, for whom, and how will you measure success? Without this, you’re building features, not value.
- Solution sketch. An overall picture of how it fits together – flows, main components, intended integrations. Not finished design, but enough to understand the scope.
- Risk map. The biggest uncertainties: a questionable integration, an unclear volume, a regulatory requirement. Naming the risks early is cheaper than stumbling on them mid-build.
- Cost range. A price span tied to scope, not an exact figure. The point is to make the main quote accurate – guesswork is replaced with evidence.
If all you get is three nice sketches and no risk map or cost picture, you’ve bought a visual exercise, not a discovery phase.
When it’s worth the money
Three situations make a discovery phase clearly worthwhile. The first is unclear requirements – when you’re not internally aligned on what to build, or the end users’ needs haven’t been explored. The second is technical uncertainty – a new integration, an unusual performance level, or a regulatory requirement no one has accounted for. The third is high stakes – when the project is large enough that a wrong turn costs hundreds of thousands of kronor to fix later.
What the three have in common: a small investment in clarity now prevents a large misinvestment later. It’s cheaper to change a sketch than a finished product.
When it just delays decisions
If the assignment is small, well-defined, and technically familiar, the discovery phase rarely adds enough to justify the delay. If you’re building something you’ve done before, with a clear requirements picture and known technology, a half-day workshop is often enough. Also watch out for discovery phases that grow into their own projects with no end date – the purpose is to reach a decision, not to investigate forever. A discovery phase without a firm deadline is a warning sign.
Reasonable scope in time and price
A discovery phase should be proportional to the project. As a rule of thumb, it lands at a few percent of the expected total cost and takes anywhere from a few days to a few weeks.
| Project size | Reasonable discovery phase |
|---|---|
| Smaller project (under SEK 500,000) | A few days, often SEK 25,000–75,000 |
| Medium-sized project (SEK 0.5–2 million) | 1–3 weeks, often SEK 75,000–200,000 |
| Large project (over SEK 2 million) | 3–6 weeks, often SEK 200,000 and up |
If the discovery phase gets more expensive than that relative to the build, it’s a sign it has grown beyond its purpose.
Two common mistakes
Discovery phases miss the mark in two opposite ways, and it’s worth recognizing both. The first is the too-thin discovery phase: a few nice sketches and a vision, but no risk map and no cost range. It looks like a decision-ready document but you can’t actually decide anything from it, and the uncertainty afterward is exactly as large as before. You’ve paid for a presentation, not for clarity.
The second is the too-thick one – the discovery phase that becomes its own project with no end date. It keeps investigating long after the answers are in, often because no one dares to call it done. The telltale sign is the lack of a firm deadline and a clear deliverable. A good discovery phase has both: a date by which it’s finished and a defined output it’s meant to result in. Put both into the order from the start, and you’ll avoid both ditches.
How the discovery phase gets reused
The value doesn’t stop when the document is finished. The target picture and solution sketch become the foundation of the requirements specification. The risk map and cost range become the basis for procurement – now several vendors can quote on the same thing, which makes the quotes comparable instead of guessed. And the roadmap guides prioritization once the build is underway, so you start with what delivers the most value.
A discovery phase that only suits its own author has half the benefit. Require a vendor-independent deliverable that someone else can build on.
At Weapp, we’re happy to start larger assignments with a defined discovery phase, precisely to make the price predictable and the risk visible. Want to know if your project needs one? Take a look at our services or get in touch with a short description of the idea.
Frequently asked questions
How much should a discovery phase cost?
A common rule of thumb is a few percent of the expected project cost – often in the range of SEK 50,000 to 200,000, depending on the project's size. The point is that a small investment in clarity should make the whole main project more accurate and cheaper to manage.
Can the discovery phase be done by a different vendor than the build?
Yes, and sometimes it's wise, to avoid locking yourselves in early. But make sure the deliverable is vendor-independent and concrete enough for someone else to be able to quote on it. A discovery phase that only suits its own author has half the value.
Is a discovery phase the same as a requirements specification?
No. The discovery phase produces the groundwork – goals, priorities, risks, and technical choices – that the requirements spec then builds on. The discovery phase answers whether and how something should be done; the requirements spec describes in detail what is to be built.
When is a discovery phase a waste of time?
When the assignment is small, well-defined, and technically familiar. If you're building something you've done before, with clear requirements and known technology, the discovery phase risks just delaying the start without reducing uncertainty. A short workshop is enough then.
What should I require as a deliverable?
A written document with a target picture, a solution sketch, a risk map covering the biggest uncertainties, and a cost range tied to scope. Ideally also a rough roadmap. It should be possible to make an investment decision based on the material – not just a polished presentation.