Why a Paid Discovery Phase Saves Money on Software Projects

"Why would I pay you before you have written any code?" It is a fair question. The honest answer is that a paid discovery phase in software development is not about code at all. It is a short, fixed piece of work that turns an idea into a plan precise enough to build from and price properly. Done well, it costs a small slice of the project budget and protects the rest. Done badly, it is an expensive document nobody reads.

What a software discovery phase should produce

Judge discovery by its outputs. At the end, you should hold:

1. A problem statement and success measures. What the software is for, who it serves, and the numbers that will tell you it is working.
2. User roles and key flows. Who uses the system and the main paths they take, mapped step by step.
3. A prioritized feature list. Every feature, sorted into what goes in the first release and what waits. The launch-day test from our guide to scoping an MVP works well here.
4. Wireframes or a clickable prototype of the main screens, ideally tried out with a few real users or staff.
5. A technical outline. Proposed architecture and hosting, and a check of every integration: does the other system have an API, what does it allow, and what does access cost?
6. A risk list. The things most likely to go wrong, with a plan for each.
7. An estimate and a release plan, given as ranges, with the assumptions written down.

You should own all of it, and another company should be able to use it if you decide not to continue with the one that did the discovery. If the output only makes sense to the vendor who wrote it, you have paid for a sales process.

Where the savings come from

Discovery saves money in a few specific, unmysterious ways.

• It finds blockers while they are cheap. The classic one is an integration. You assume your practice software, ERP or courier has an API that lets you write data, and it turns out to be read-only, or only available on an enterprise plan. Found in week one of discovery, that is a planning change. Found in month three of a build, it is a rewrite.
• It changes pictures instead of code. Moving a button, merging two screens or rethinking a flow takes minutes in a wireframe and days in a built app.
• It shrinks the uncertainty in the estimate. A vendor quoting from a two-paragraph brief has to pad for everything they do not know. After discovery there is less to pad for, so fixed prices get tighter and time-and-materials estimates get more reliable.
• It removes features nobody needs. Walking through real workflows with the people who will use the system tends to expose features that sounded necessary and are not.

Discovery can also tell you not to build at all. The UK government's service manual, which sets out how public-sector digital services are run, is direct about this. Its guidance on how the discovery phase works says it is not a failure to stop at the end of discovery if the research shows that is the right thing to do, because you save time and money that could be better spent elsewhere. It also says plainly that you should not start building in discovery. A private business deserves the same discipline.

A worked example: four clinics and a booking problem

Imagine a physiotherapy group with four clinics that wants a patient app: book appointments, pay, see the exercise plan their physio set, and message the clinic. The first brief is a page long. Without discovery, vendors would quote across a wide range, each assuming something different about how bookings reach the clinic's existing practice management software.

A three-week discovery might run like this:

• Week one: interviews with two physios, the front-desk lead and five patients, plus a review of the practice software and its API documentation.
• Week two: user flows and wireframes for booking, payment and exercise plans. A technical test confirms that the practice software's API can read appointment slots but cannot create bookings.
• Week three: three options for the booking problem (embed the software vendor's own booking widget, request write access from that vendor, or take bookings in the new system and enter them manually for a first phase), a prioritized feature list, a risk list, and an estimate range for each option.

Two things change as a result. Messaging drops out of version one, because the front desk already handles messages by phone and does not want another inbox to watch. And the booking approach is chosen with the trade-offs visible, instead of being discovered halfway through the build. The clinic group ends up with an estimate it can rely on and a document any competent vendor could quote from.

How long discovery takes and what it costs

For a small or mid-sized business project, discovery commonly takes one to four weeks and needs a small group: someone to lead the analysis, a designer for the wireframes, and a senior engineer for the technical checks. Large or regulated systems take longer; the GOV.UK guidance above describes around 4 to 8 weeks as typical for a government service.

As a rough market range, expect discovery to cost somewhere around 5–15% of the likely build budget, depending on how much research and prototyping you want. It is usually sold as a fixed fee with a fixed list of deliverables, which is one of the few places where a fixed price nearly always makes sense, because the scope is the work itself. If you want a reference point, here is how our pricing is structured.

When you can skip it

Discovery is not always worth paying for. You can reasonably skip it or shrink it when:

• The project is small and well understood, such as a marketing website or a standard Shopify store.
• You are rebuilding an existing system whose behavior is documented and whose users are happy with how it works.
• You already have a clear requirements document that developers can quote from, plus designs, and the integrations are known and tested.
• The budget is so small that discovery would eat a large part of it. A one- or two-day scoping workshop is the better fit.

How to judge a discovery proposal

Before you pay for one, ask the vendor:

1. Who will do the work: engineers and designers, or salespeople? The technical checks need someone who has actually built integrations.
2. What exactly will we receive, in what format, and will we own it?
3. Will you talk to our staff and customers, or only to management?
4. Will the estimate at the end be a range, with its assumptions written down?
5. If we do not continue with you, can another company build from what you give us?
6. What happens if discovery shows we should not build this?

A vendor who answers the last question with "then we tell you so" is one worth listening to.

Where to start

If your project has more than a handful of screens, touches other systems, or needs a budget you can defend to someone else, start with discovery. Write down what you know, list what you do not, and ask for a fixed-scope, fixed-fee discovery with the deliverables listed above.

If you would like to talk through what discovery would cover for your project, our IT consulting team can outline it with you, and tell you when a shorter scoping session is all you need.