Discovery phase
A discovery phase is a fixed-scope engagement, usually one to three weeks, that turns a software idea into a costed plan and a build-or-not decision before any production code is written. It is the stage at which risk is cheapest to remove, because nothing has been built yet.
Also known as: Discovery sprint, Product discovery, Scoping phase, Inception
Last reviewed
Why a discovery phase matters
Most software overruns are traceable to decisions made before the build, not mistakes made during it. A requirement nobody questioned, an integration nobody checked, a user group nobody spoke to. Discovery exists to find those things while changing your mind is still free.
It also makes estimates meaningful. A quote produced from a one-line description prices a supplier's interpretation of what you meant; a quote produced after discovery prices something both sides have written down. That is the difference between a number you can take to a board and a number you will renegotiate.
What a discovery phase produces
A good discovery ends with artefacts, not a feeling of alignment. Typically: the business outcome stated as a measure, a list of user types and what each can do, the systems involved and whether they can actually be connected, the risks with an owner against each, a prioritised scope for the first release, and a costed plan.
The single most valuable output is often the list of things deliberately excluded. An agreed "not now" list is what stops the first release growing quietly, and it is the document people return to six weeks later.
Discovery phase vs requirements gathering
Requirements gathering is an activity: establishing what the software needs to do. A discovery phase is a bounded commercial engagement that contains requirements gathering along with feasibility checks, risk analysis, estimation and a recommendation.
The practical difference is the decision at the end. Requirements gathering assumes the project is happening and asks what to build. Discovery is allowed to conclude that you should not build at all, or should buy something instead — which is why it has to be scoped and paid for as work rather than absorbed into a sales process.
When you need one
Run discovery when the project is large enough that being wrong is expensive, when several teams or systems are involved, or when you need a defensible number before committing budget. On our AI Opportunity Planning engagements, a focused scoping engagement starts around £1,500 and a fuller, multi-process discovery is typically £3,000 to £6,000, with most running in one to two weeks.
It is worth running even when you are confident, because the cost is small against a build budget and the output is yours to take to any supplier. If discovery concludes you should buy a product instead of building one, it has paid for itself many times over.
Discovery phase: common questions
Usually one to three weeks, depending on how many processes and systems are in scope. On our AI Opportunity Planning engagements most run in one to two weeks. Longer than about a month and discovery has normally become a project in its own right, which defers the decision it was meant to bring forward.
Yes, and a supplier who gives it away free has to recover the cost somewhere, usually by quoting defensively or through change requests. Paying for it also means you own the output and can take it to another supplier, which is the clearest test of whether the work was genuinely for you.
It should be allowed to, and that is the main thing distinguishing it from a sales exercise. Concluding that an off-the-shelf product fits, or that the process is not ready to be automated, saves the entire build budget and is a successful outcome rather than a failed engagement.
Want to talk about your project?
Tell us what you’re trying to achieve and we’ll map the fastest credible path.