A software discovery phase should cost 5–10% of the project budget, take two to six weeks, and produce a scope you could hand to any supplier: the mapped process, the exceptions, a prototype, a risk register, and a costed roadmap. Industry figures consistently show that spending it reduces development overspend by 40–60%: roughly $7,000 of discovery on a $100,000 build preventing $40,000–$60,000 of overrun.
This guide covers what discovery should deliver, what it costs, how long it takes, and how to tell a real discovery from a sales exercise wearing its clothes.
Key takeaways
- Budget 5–10%, expect $5,000–$40,000: Scaled to project size; MVPs at the bottom, enterprise systems at the top.
- Two to six weeks is normal: One week for a simple MVP, four to eight for a large enterprise system.
- The exceptions are the deliverable: The happy path is easy to map and is not where cost lives.
- Own the output: A paid discovery you can take to any supplier is worth several times a free one.
What discovery is for
Discovery converts an intention into a scope someone can price and build. It exists because the expensive decisions in software are made before any code is written, and because requirements discovered mid-build cost several times more to resolve than requirements discovered before it.
It is not a sales meeting, a wireframe exercise, or a document produced to justify a proposal that already exists. The test is whether the output would be useful if you took it to a different supplier.
What it should deliver
| Deliverable | What it contains | Why it matters |
|---|---|---|
| Process map | The current workflow as it actually runs, with volumes and timings | Interviewing managers gives the intended process; following cases gives the real one |
| Exception catalogue | Every awkward case, its frequency, and how it is handled today | Determines the real cost, and whether the system gets adopted or bypassed |
| Requirements specification | Functional and non-functional, written to be testable | The basis for a comparable quote from anyone |
| Clickable prototype | The main journeys, testable with real users | Surfaces misunderstanding before it is expensive |
| Architecture outline | Systems, integrations, source-of-truth rules, data flow | Where integration risk becomes visible |
| Risk register | Named risks, likelihood, and mitigation | Turns unknowns into decisions |
| Costed roadmap | Phased scope with estimates and a recommended first release | The output the budget conversation needs |
A discovery that produces only a proposal has told you about the supplier rather than about your project.
What it costs and how long it takes
| Project size | Discovery duration | Typical discovery cost |
|---|---|---|
| Simple MVP | 1–2 weeks | $5,000–$10,000 |
| Standard business application | 2–4 weeks | $10,000–$20,000 |
| Multi-surface platform | 4–6 weeks | $20,000–$30,000 |
| Enterprise or regulated system | 4–8 weeks | $30,000–$40,000 |
Longer than eight weeks usually means the scope was never bounded. Shorter than a week means the exceptions were not found, and exceptions are what determine the real cost.
The arithmetic is what makes this an easy decision. Discovery at 5–10% of budget reduces overspend by 40–60%, against the background rate of roughly 60% of software projects exceeding their initial budget. Skipping it does not remove the work; it moves the work into the build, at build rates, after the price is fixed.
Map the process by following cases, not by asking
Interviewing managers produces the intended process. Following individual cases end to end produces the actual one, and the gap between them is where projects fail.
Sit with the people doing the work. Trace real cases: every step, who performs it, how long it waits between steps, and what happens when something is missing. Capture the spreadsheets, the messaging threads, the side notes and the informal escalations, because those workarounds encode rules no process document contains.
Keep the output readable by anyone in the business. A map that needs the consultant to interpret it will not be used after they leave.
Insist on the exception catalogue
The routine 80% of a process is straightforward to automate. The remaining 20% decides whether the system is adopted or quietly bypassed.
Discovery should list the exceptions, how often each occurs, and what happens today: then recommend which the software handles, which route to a person, and which the business should stop allowing. That third category is often the most valuable output, because some exceptions exist only because nobody has been asked to justify them.
If the exception list is short and tidy, it is incomplete. Real processes accumulate awkward cases, and a discovery that found none was talking to the wrong people.
Expect open questions in the output
A discovery that answers everything is either unusually simple or not being honest. Some things are genuinely unknowable until you build: how staff will respond to a changed workflow, whether an undocumented legacy integration behaves as described, what volume looks like at peak.
The right output names these, states what would resolve each, and recommends how the first phase can reduce the uncertainty cheaply. That is what separates discovery from a proposal in discovery's clothing.
Pay for it, and own the output
Free discovery is priced into a proposal you have not agreed to, and it is designed to lead somewhere. Paid discovery, with a contract stating the output is yours to use with any supplier, costs a fraction of a build and changes the incentives entirely.
It is also the cheapest way to evaluate a partner. How a firm behaves during a paid discovery, whether they ask about your exceptions, whether they tell you something you did not want to hear, predicts delivery behaviour far better than a reference call.
Who needs to be in it
Discovery fails when it involves only the sponsor and the supplier. It needs the people who do the work daily, someone who can decide what the process stops doing, and whoever owns the systems it must integrate with.
That last group is regularly omitted and is the most common source of a surprise in month two. An integration that "should be straightforward" frequently turns out to need a change on the other side, owned by a team with its own roadmap.
When you can skip it
Discovery is unnecessary when the scope is genuinely small and well understood, a single integration between two documented systems, or a change to something you already run. Below roughly $20,000 of build, a formal discovery can cost more than the risk it removes.
Above that, and for anything touching several teams or systems, skipping it is not a saving. It is a decision to discover the same information later, at a worse price, after the commercial terms are already fixed.
Related guides
- Alongside Software Discovery: Goals, Activities, and Deliverables, continue with How to Build a Business Case for Custom Software.
- Alongside Software Discovery: Goals, Activities, and Deliverables, continue with How to Choose a Digital Transformation Partner.
If the work prompted by Software Discovery: Goals, Activities, and Deliverables leads to a funded initiative that needs product strategy, design, engineering, or integration support, Discuss Your Software Project.
Ali Boran Gazel