The Discovery Phase in Software Development: What You Get For It

The discovery phase in software development buys you a scope somebody can actually build to, and an estimate whose range you can defend to a finance director. That is it. No software, no screens you can click, nothing to show the board. For the first slice of a budget it feels like the worst value on the invoice, which is why clients try to cut it, and why I spend more time arguing for it than for any other line.

Ten years of quoting projects has left me with one reliable pattern: the projects that went badly were almost never the ones where the technology was hard. They were the ones where we started building before somebody had answered a question nobody thought to ask.

What discovery actually is

Discovery is a paid, time-boxed piece of work whose output is documents. It sits between "we would like to build something" and "here is what it costs to build it", and the work is interrogation rather than design: what has to be true for this to work, what happens when it is not, and what have we all assumed without saying it aloud.

It is not a sales workshop. A free two-hour call where an agency asks about your goals is qualification, and every agency does it, including us. Discovery is the thing you pay for, with named deliverables and a deadline.

It is also not design. Wireframes may come out of it, but the point of them in discovery is to expose disagreement, not to look good. A flow diagram that starts an argument between two of your stakeholders has already paid for itself.

What you should get for the money

This is the part to be demanding about. The test I would apply as a buyer: could you hand the output to a completely different supplier and get a comparable quote back? If not, you bought consultancy theatre.

A written scope that names what is excluded

Every scope document lists what is included. The valuable half is the exclusions. "Single currency only", "English interface only", "no offline mode", "no bulk import in phase one", "admin users are created manually".

Exclusions are where fixed price projects die, because an unstated exclusion is heard as an inclusion by whoever is paying. If your scope document has no exclusions section, it is not finished.

A domain and data model

What are the objects in this system, what do they contain, and how do they relate? An invoice belongs to a customer, has many lines, has a status, can be partially paid — and the moment you write "partially paid" down, you have to decide how a payment gets allocated across several outstanding invoices.

That is exactly the kind of question that looks trivial in a meeting and takes a week of rework if it is decided wrongly in month three. The billing platform in our HisaabKar case study allocates payments to the oldest invoice first and costs inventory on a first-in-first-out basis. Those are single sentences. They are also structural decisions that touch nearly every screen, and they belong in discovery, not in a code review.

Interface flows for the paths most likely to be wrong

Not every screen. The three or four journeys where the business logic is contested: onboarding, the money path, the failure path, whatever your team argues about.

A technical approach and a complete integration list

Every external system, and for each one: does it have a documented API, what does authentication look like, are there rate limits, is there a sandbox, and who owns the credentials. Integrations are the most reliably underestimated part of any build, and the only cure is to make somebody actually read the documentation before quoting.

The hosting model, the data storage decisions and anything with a compliance implication belong here too.

A risk register with owners

A short list of the things that could go wrong, what each would cost, and who is responsible for finding out. "The legacy export may not include historical attachments — client to confirm by the 10th" is worth more than a page of architecture diagrams.

An estimate with its assumptions attached

Not a number. A number with a range, a list of what it assumes, and a breakdown by phase. Assumptions are what turn an estimate into something you can hold a supplier to, because when one of them turns out to be false, both parties can see immediately why the number moved.

How discovery changes an estimate

An estimate before discovery and an estimate after discovery are different kinds of statement, and the difference is not accuracy. It is confidence.

Before discovery, a supplier is pricing a description. The honest version of that estimate is a wide range — wide enough that clients sometimes think they are being fobbed off. To be clear that this is illustration and not a benchmark: if the top of the range is three or four times the bottom, that is not a bad estimate, it is a correct expression of how little anyone knows. The dishonest version is a single confident number, and it is dishonest whether it turns out high or low.

After discovery, the range narrows because the unknowns have been converted into decisions. Not eliminated — narrowed. Anyone promising a precise figure is quoting their buffer, not their estimate.

What this means commercially is that discovery is what makes a fixed price possible at all. You cannot fix the price of something nobody has examined, which is the core argument in fixed price vs time and materials. A phased fixed price — scope a phase properly, fix its price, leave later phases as a range — only works because discovery closed the first phase's scope.

Why refusing discovery makes a project more expensive

The argument against discovery is that it delays the build and spends money on paper. Both are true. It is still the wrong call on most projects, for a reason that has nothing to do with process ideology.

The cost of changing a decision rises with how much has been built on top of it. Changing a data model in a document costs an afternoon. Changing it after forty screens read from it costs a migration, a rewrite of everything that touched it, and a retest of all of it. Nothing about that is controversial; it is just easy to discount when the afternoon is the thing you can see and the migration is hypothetical.

Skipping discovery does not remove the work. Every question discovery would have answered still gets answered — during the build, by a developer, under time pressure, usually by guessing, and usually correctly about eight times out of ten. It is the other two that hurt.

The second-order effect is worse. Without a scope document, there is no agreed baseline, so there is no way to distinguish a change from a misunderstanding. Under a fixed price that becomes a dispute about what was promised. Under time and materials it becomes a bill you did not expect. Either way, the relationship absorbs damage that a week of writing things down would have prevented.

The pattern shows up most sharply in projects that were built at speed with no scoping at all, which is the situation we describe in rebuilding an AI-built app for production. The code exists. What is missing is any record of what it was supposed to do.

When discovery is genuinely unnecessary

I am not going to pretend it is always right. There are four cases where I would tell a client to skip it.

The work is small. If the whole job is a fortnight, a discovery phase is overhead. Scope it in a call, write a page, start.

The scope already exists. Some clients arrive with a specification a previous team wrote, or a product they are rebuilding feature-for-feature. Discovery's job is then reduced to validation, which is a day or two, not a phase.

You are repeating something. The fifth site of a pattern we have built four times does not need its requirements discovered. A well-defined web design and development engagement with a signed-off design and a known content structure falls into this category most of the time.

It is a rescue. When the job is to take over an existing codebase, reading the code is discovery. A technical audit replaces the requirements work, because the requirements are already encoded — badly, but encoded.

What these have in common is that the unknowns are small or already resolved. That is the actual test. Discovery is proportional to uncertainty, not to budget.

What discovery should cost and how long it should take

Two things to insist on: a fixed price, and a fixed end date.

Discovery is the one part of a software project whose scope genuinely is knowable in advance, because you are producing a defined set of documents. If a supplier cannot quote it as a fixed piece of work, be suspicious. An open-ended discovery is a retainer.

It is normally priced as a small share of the expected project value, and it should be quoted as a number before it starts. I would not give you a percentage to hold me to here, because it varies with how much uncertainty there is to remove — and a figure in a blog post is exactly the kind of thing that gets quoted back as a benchmark it never was.

Two clauses to put in the discovery agreement:

• You own the output. If you do not continue, the documents are yours to take elsewhere. This is the clearest signal of whether a supplier believes in the work or is using it as a sales process.
• Continuing is optional. Discovery that automatically commits you to the build is not discovery. Its most valuable possible outcome is the conclusion that the project should not go ahead, and a supplier who has already booked the build cannot deliver that conclusion honestly.

That second point is worth sitting with. The best discovery I have run ended with a client not building anything, because the process we mapped turned out to be solvable with a product they could subscribe to. That is the build versus buy question, and discovery is often where it finally gets answered properly.

Running one that is worth paying for

If you are on the buying side, these are the things that make the difference:

• Put your difficult stakeholder in the room early. The person who will object at the end should object at the start. It is the cheapest objection they will ever make.
• Bring real data. A sample export, a real invoice, an actual customer record. Discovery run on descriptions of data produces systems that break on the first import.
• Answer the boring questions. What happens to a cancelled order that was partially refunded? Who can delete a user? These are the questions that determine how much of the system has to be rebuilt later.
• Insist on written exclusions. Ask directly: what is not in this? A supplier who cannot answer has not scoped it.
• Read the risk register properly. It is the most honest document you will get from any agency, and most clients skim it.

For mobile work the same rules apply with one addition: platform behaviour, store review requirements and offline handling need deciding in discovery rather than discovered in beta, which is why we treat it as non-optional on app development projects of any size.

The decision rule

Run a discovery phase when you cannot yet write down what "finished" means, when more than one team has to agree on what the system does, or when anybody is about to quote you a fixed price for something nobody has examined.

Skip it when the work is small, the scope is already written, or the answers already exist somewhere you can read them.

And if a supplier is willing to give you a firm price without either discovery or a written scope, treat that as information rather than as a favour. They have either built this exact thing before, or they have priced their uncertainty and are hoping you do not ask which. The rest of what to ask before signing is in questions to ask a web developer before hiring.