What Happens in a Software Discovery Phase (and Why Skipping It Costs More)
Key takeaway
Discovery is a short, fixed-price phase — typically two to four weeks and 5–10% of project cost — that produces a validated scope, an architecture, a prioritized backlog, and a real estimate. Its output should be useful even if you take it to a different vendor.
Discovery is the phase clients most want to skip, because it produces documents rather than software. It's also the phase that determines whether the estimate you're given bears any relationship to what you'll eventually pay.
What actually happens
- Stakeholder interviews — what the business needs, what each role does today, and what "success" means in numbers.
- Current-state review — existing systems, data, and integrations, including the spreadsheets doing load-bearing work.
- Workflow mapping — the end-to-end journeys the software must support, as steps rather than features.
- Technical architecture — the stack, integration approach, data model outline, and the non-functional requirements that drive cost.
- Prioritized backlog — scope split into a phase one that ships and a later list that doesn't hold it up.
- Estimate and plan — timeline, team shape, and cost with the assumptions written down.
What you should get at the end
A scope document, wireframes or a clickable prototype of the core flows, an architecture outline, a risk register, and a milestone plan with an estimate. Insist that these are yours to keep. A discovery whose output only makes sense to the vendor who produced it is a sales exercise wearing a different name.
Time and cost
- A small product: one to two weeks, often 5% of the projected build.
- A mid-size business application: two to four weeks, 5–10%.
- An enterprise platform with migration and compliance: four to eight weeks, and worth every day.
Why skipping it is the expensive option
Without discovery, the vendor prices an imagined system and you approve a number neither party can defend. The gap surfaces in month three as change requests, and by then the architecture has been committed to assumptions nobody validated. Requirements defects found after build routinely cost an order of magnitude more to fix than the same defect caught in a workshop — which is precisely the trade discovery makes.
How to tell a good discovery from a sales process
- It includes people who will actually use the software, not only the people paying for it.
- It produces at least one recommendation that reduces scope or cost.
- It names risks plainly rather than presenting everything as straightforward.
- Its deliverables are portable — you could hand them to another firm and get a comparable quote.