A discovery phase for enterprise software is a three to eight week engagement, costing $15,000 to $60,000 (€13,000 to €50,000, £11,000 to £44,000) or 3 to 7 percent of the build, that produces a written scope, a map of the systems and data involved, a validated design for the core journeys, a technical approach, a risk register and a phased plan with a price you can hold a vendor to. It is worth paying for because the estimate it replaces is typically wrong by 50 percent or more, and because its output belongs to you and can be used with any vendor.
Prices are in US dollars. Euro and pound figures in parentheses are approximate, rounded conversions. Quotes are issued in the currency of your contract.
Enterprise software proposals arrive in two forms. One is a price for the whole system, produced from a requirements document and a few calls, with a confidence nobody in the room actually has. The other is a price for a short piece of work whose output is a scope, a design and a real estimate. The first feels decisive and is usually wrong by half. The second feels like a delay and is the fastest route to a system that ships on budget. This post explains what the second one produces, what it costs, and how to use it.
What does a discovery phase deliver?
| Deliverable | Why it matters | Who signs off |
|---|---|---|
| Problem statement and success measures | One page on what the system must change in the business and how you will know. Everything else is tested against it. | Executive sponsor |
| Stakeholder and user map | Who uses it, who approves it, who is affected and who can stop it. Projects fail on the people this misses. | Sponsor and department heads |
| Current-state process and system map | How the work actually flows today, which systems hold which data, and where the manual handoffs are. | Operations lead and IT |
| Written scope with in and out lists | The features of release one, the features deliberately deferred, and the assumptions. The document a price is attached to. | Sponsor, operations lead |
| Core journey designs, usually a clickable prototype | The three to five journeys that carry most of the value, tested with real users before anything is built. | Users and operations lead |
| Technical approach and integration plan | Stack, hosting, how each existing system is connected, data ownership, security model. Checked against IT's standards. | IT or architecture lead |
| Data assessment | What data exists, its quality, what must be migrated and what must be cleaned first. | Data owner |
| Risk register | What could derail the build, with an owner and a response for each. Partner APIs, regulation, key people, legacy quirks. | Sponsor and PMO |
| Phased plan and estimate | Releases, durations, team shape and a price with a stated confidence range, usually within 15 to 20 percent. | Sponsor and finance |
Each deliverable is a document or a prototype you can open, share and hand to another team. If a vendor's discovery produces slides and a bigger number, it was a sales process.
How long does it take and what does it cost?
Three to eight weeks, depending on the number of systems, departments and user types involved. A departmental tool with two integrations is at the short end. A core platform touching the ERP, CRM, warehouse and a partner API, with four departments as users, is at the long end. The cost is $15,000 to $60,000 (€13,000 to €50,000, £11,000 to £44,000), which works out to 3 to 7 percent of the build it defines. For a program in the $600,000 to $2,000,000+ (€520,000 to €1,740,000+, £445,000 to £1,480,000+) range, discovery may be structured as a first phase of its own, with its own budget line and steering review at the end.
The team is small and senior: a lead engineer or architect, a designer, a business analyst or product lead, and a project manager for part of the time. On your side it needs the sponsor for a few hours a week, the operations lead and IT for workshops, and access to real users for testing the prototype. The most common cause of a slow discovery is slow access to those people.
What changes in the estimate after discovery?
Almost everything, and usually in both directions. The things that were assumed simple turn out to be hard: the ERP has no usable API for the data you need, the approval process has eleven variants, the data in the legacy system needs cleaning before anything can be migrated. The things that were assumed hard turn out to be unnecessary: half the requested reports are never read, the second user role can wait a year, the real-time requirement was a preference. The net effect is an estimate that is grounded in what will actually be built, with a confidence range the vendor will commit to.
| Estimate basis | Typical confidence | What it is good for |
|---|---|---|
| Requirements document and two calls | Plus or minus 50 percent or worse | Deciding whether to look seriously at the idea |
| Discovery output | Plus or minus 15 to 20 percent | Approving a budget and signing a contract |
| Discovery plus a first delivered phase | Plus or minus 10 percent for the next phase | Committing to the rest of the program |
This is why budgeting a multi-year program starts with a discovery figure and a range, not a single number for the whole program. It is also why software projects go over budget: a confident price on a thin basis sets a number the project was never going to hit.
When can you skip discovery?
- You have just done one. A recent, documented scope from a previous vendor or an internal team is a valid starting point. A good vendor will review it in a week rather than redo it.
- The work is a known extension. Adding a module to a system the same team built last year, with the same users and data.
- It is genuinely small. A single workflow with one integration and one user type can be scoped in a few workshops as part of the build.
- You are buying time and materials with a senior team. Discovery then happens in the first sprints, with the same output, and the estimate firms up as it goes. This works when you can tolerate the range.
You cannot skip it for a fixed price on a system that touches more than two existing systems or more than one department. Any vendor offering one has either priced in a large margin or will recover the difference in change requests. Fixed price vs time and materials covers how the contract and the discovery fit together.
What do you do with the output if you change vendor?
Use it. Discovery output should be written to be usable by any competent team, and the contract should say it belongs to you on payment, with no restriction on sharing it. In practice this means the scope, the prototype files, the system map, the technical approach and the risk register go into the RFP for the build, and vendors quote against them. Quotes based on the same discovery output are comparable in a way that quotes based on a requirements document never are. How to write an RFP for custom software development shows where each document goes.
Some clients deliberately run discovery with one vendor and tender the build. That is legitimate, and a vendor confident in their discovery work will accept it. The vendor who did the discovery has an advantage in the tender, since they understand the system, and that advantage is earned.
What does a bad discovery look like?
- It is free. A free discovery is a sales call with workshops. Its output is a proposal, not a scope.
- It produces no prototype. Journeys described in words have not been tested with the people who will use them.
- IT was not in the room. The technical approach will meet your standards for the first time at contract review.
- Everything is in scope. A discovery that cuts nothing has not made any decisions.
- The estimate has no range. A single number after discovery is a guess with a decimal point.
- You cannot take the output elsewhere. The contract restricts it, or it is written so only that vendor can read it.
Discovery in one paragraph
Three to eight weeks. $15,000 to $60,000 (€13,000 to €50,000, £11,000 to £44,000). A senior team of four working with your sponsor, operations lead, IT and real users. Output: a written scope, a tested prototype of the core journeys, a system and data map, a technical approach, a risk register and a phased plan with a price within 15 to 20 percent. Yours to keep and to tender with.
How 7L approaches this
7L International is a custom software and digital transformation firm with business hubs in New York, London and Athens, founded during the Greek financial crisis and now with more than one hundred organizations supported. Discovery is a separate, paid, short engagement for us, with the deliverables in the table above and a price at the end that we commit to within a stated range. The output is yours whether or not we build what it describes, and we have had clients tender it. It is the first of the end-to-end steps described in what end-to-end really means, and the enterprise software development guide shows what follows it. If you have a requirements document and a number you do not trust, talk to us about a discovery that replaces the guess.
Frequently asked questions
How much does a software discovery phase cost?
$15,000 to $60,000 (€13,000 to €50,000, £11,000 to £44,000) for an enterprise system, taking three to eight weeks, which is 3 to 7 percent of the build it defines. The range depends on the number of systems to integrate, departments involved and user types to design for. For programs above $600,000 (€520,000, £445,000) it is usually budgeted as a phase of its own with a steering review at the end.
What is the difference between discovery and a requirements document?
A requirements document lists what people have asked for. Discovery works out what the system must do, tests the core journeys with real users as a prototype, maps the systems and data it depends on, and attaches a price with a confidence range. The requirements document is an input to discovery, and roughly a third of it usually ends up on the deferred list.
Should discovery be done by the vendor who will build the system?
Usually, because the understanding carries into the build and the estimate is theirs to honor. But the output should be written so any team could use it, it should belong to you on payment, and you should feel free to tender the build with it. A vendor who objects to that is telling you something about their confidence in the work.
Can we get a fixed price without a discovery phase?
Not an honest one for a system that touches more than a couple of existing systems or departments. A fixed price before discovery is either padded with margin or will be recovered through change requests once the real scope appears. Discovery is what makes a fixed price for the first phase possible, and a committed range for the rest.
What do we need to provide during discovery?
A sponsor available for a few hours a week with the authority to make scope decisions, an operations lead and someone from IT for workshops, access to the systems and data being mapped, and five to ten real users for an afternoon of prototype testing. Slow access to those people is the most common reason discovery runs long.