Software Discovery Phase Explained: What Happens Before the Code

Most software projects that go badly wrong were doomed weeks before anyone opened an IDE. Not because the developers were bad, but because nobody had properly worked out what needed building, for whom, and why. That gap has a name: the discovery phase, and it is the part of a software project most likely to get squeezed when a client is impatient to see progress.

Key Takeaways

A discovery phase turns a vague idea into a scoped, buildable brief before any development budget is spent on code that might get thrown away.
Skipping discovery does not remove the work, it just moves the cost of finding out what the client actually needs into the middle of the build, where changes are far more expensive.
A properly run discovery phase produces concrete outputs: user needs, technical constraints, a prioritised feature list and a realistic estimate, not just a slide deck.
Discovery works best as a fixed, time-boxed piece of paid work, typically one to four weeks, rather than an open-ended discussion folded into the sales process.
The clearest sign a discovery phase was skipped is a project that keeps changing scope mid-build because requirements were never properly tested against reality.

Clients often assume discovery is a delay tactic, a way for an agency to bill hours before doing “real” work. In practice it is closer to the opposite: a short, structured stage that stops the expensive part of the project, the actual build, from being spent on the wrong thing.

What a Discovery Phase Is Actually For

A software discovery phase is a defined stage, usually running one to four weeks, where a technical team works with the client to turn a business problem into something that can be estimated and built. It sits before any commitment to a fixed scope or budget, and its job is to remove the biggest unknowns.

The UK government’s own service standard, first published in 2016, treats discovery as a formal, distinct stage of any digital project, not an optional extra. Its service manual describes discovery as the point where a team establishes “what problem you’re trying to solve” and whether a digital solution is the right answer at all, before committing to build anything.

That last part matters. A good discovery phase is allowed to conclude that the client’s first idea is not the right one, or that a smaller version of it would deliver most of the value at a fraction of the cost. An agency that only ever confirms what the client already believed is not really running a discovery process, it is running a sales pitch with extra steps.

Two colleagues reviewing sticky notes on a whiteboard during a planning session

What Gets Produced

A discovery phase that is done properly leaves the client with tangible artefacts, not just conversation. Typically that includes a written statement of the problem being solved, a list of who will use the software and what they need from it, the technical constraints (existing systems it has to talk to, compliance requirements, hosting restrictions), a prioritised backlog of features split into must-have and nice-to-have, and a cost and timeline estimate the client can actually hold the delivery team to.

The British Computer Society made a related point in a 2007 piece on why IT projects fail: the value of documenting decisions properly, rather than relying on shared memory of a meeting, is that everyone, client and delivery team, has something concrete to refer back to when disagreements about scope arise later in the project.

Why Discovery Gets Skipped, and What It Costs

The pressure to skip discovery usually comes from the same place: a client wants to see something built, and a lengthy scoping exercise feels like the opposite of progress. Agencies under pressure to win the work sometimes go along with this, promising to “figure it out as we go.”

Skipping discovery does not remove the work of finding out what the client needs, it just moves that work into the build, where it costs far more to fix.

The National Audit Office’s 2017 review of government digital transformation programmes found repeatedly that projects which under-invested in early-stage scoping ran into the same problems later: requirements that shifted mid-build, technical constraints that surfaced too late to design around cheaply, and budgets that had to be renegotiated once the real scope became clear. None of that is unique to government IT, it is the standard failure mode of any software project that treats discovery as optional.

The Agile Alliance’s own description of iterative development assumes that a team has already established a rough shape of the problem before the first sprint starts. Agile is often misread as licence to start coding immediately and work out requirements as you go, but the methodology was never meant to replace understanding what you are building, only to make delivery more adaptive once that understanding exists.

A closed laptop on a desk with a project planning board visible on the wall behind it

The Real Cost of Getting It Wrong

Changing a requirement during discovery costs almost nothing, it is a conversation and a revised document. Changing the same requirement three months into a build, after code has been written against the wrong assumption, means rework, re-testing and often a difficult conversation about who absorbs the extra cost. This is the argument for discovery that tends to land with commercially minded clients: it is not about process for its own sake, it is about where in the project timeline a mistake is cheapest to catch.

Development teams that work across health, public sector and regulated industries feel this most acutely, because requirements there are rarely just functional preferences, they are often legal or clinical constraints that cannot be discovered halfway through a build without serious consequences. It’s a lesson software developer Arch has built into how it scopes every engagement, running a structured discovery stage before any fixed-price build commitment, precisely because the projects it takes on tend to carry that kind of regulatory weight.

Running a Discovery Phase Well

A discovery phase does not need to be exhaustive to be useful. The point is not to document every possible edge case, it is to surface the assumptions that would be expensive to get wrong and test them before committing budget. That means talking to actual users where possible, not just the person commissioning the project, and it means being honest with the client about trade-offs rather than telling them what they want to hear.

It also means treating discovery as a deliverable in its own right, with a fixed price and a fixed end date, rather than letting it drift into an open-ended series of workshops. A client who cannot see where discovery ends and delivery begins has no way of knowing whether they are getting value from the stage, which is often exactly why it gets cut from projects where it was needed most.

Frequently Asked Questions

How long should a software discovery phase take?

Most discovery phases run between one and four weeks, depending on the complexity of the problem and how many stakeholders need to be consulted. A phase that drags on for months has usually stopped being discovery and started being indecision.

Does every software project need a discovery phase?

Small, well-understood pieces of work, like a straightforward website update, often do not need a formal discovery stage. Anything involving multiple user types, integrations with existing systems, or regulatory constraints benefits from one, because the cost of an undiscovered problem rises sharply once code exists.

Who should be involved in discovery?

At minimum, someone who understands the business problem and someone who understands the technical constraints. Where possible, actual end users should be involved too, since assumptions made by commissioning stakeholders about what users need are a common source of expensive mid-project surprises.

Is a discovery phase the same as a requirements document?

Not quite. A requirements document is one output of discovery, but the process also includes testing assumptions, identifying constraints and often revising the original idea. A requirements document written without that process behind it tends to be a wish list rather than something a delivery team can actually estimate against.

What happens if discovery reveals the original idea was wrong?

A good discovery phase is allowed to say so. The point of running it before committing budget is precisely to catch this early, when changing direction costs a few days of conversation rather than months of rework.