A software discovery phase is the short, structured planning stage at the start of a bespoke software project, before any code is written. The supplier and client work together to agree the problem, the users, the core requirements and a realistic plan, budget and timeline.
Why a project starts with discovery
Commissioning bespoke software is a sizeable commitment, and the most expensive mistakes are made early: building the wrong thing, or building the right thing on a budget that was never realistic. Discovery exists to remove that risk before money is spent on development.
It is a recognised first stage, not a sales formality. The UK Government's Service Manual for agile delivery defines discovery as the opening phase of a project, the point at which a team learns about the problem and the people it affects before deciding whether and how to build.
For a buyer, discovery turns a vague idea into something you can make a confident decision on. By the end of it you should know what the software needs to do, roughly what it will cost and whether to proceed at all.
What happens during a discovery phase
Discovery is mostly conversation and analysis rather than coding. A typical phase for a small or medium-sized business involves:
- Workshops: structured sessions where the supplier asks how your business works today, what is going wrong and what a good outcome looks like.
- Understanding the users: identifying who will actually use the software day to day, since their needs shape every later decision.
- Defining the requirements: turning those conversations into a clear list of what the software must do, separating the essentials from the nice-to-haves.
- Outlining the approach: a first view of how the software might be built and hosted, enough to support a sensible estimate.
Good discovery also covers the unglamorous questions: which existing systems the software must work with, what data is involved and any rules or regulations that apply. These are the details that quietly wreck a budget when they surface late. Where one of those details carries real technical doubt, discovery may include a short proof of concept to test it before the build is costed.
What a discovery phase produces
Discovery ends with documents, not software. The exact set varies by supplier, but a buyer should expect most of the following:
- A requirements pack: a written record of what the software must do, often the basis of a software requirements specification. It usually separates functional and non-functional requirements.
- An agreed scope: a clear line around what is included in this project and, just as importantly, what is not.
- An estimate: a realistic cost and timeline for the build, grounded in the requirements rather than guessed at.
- Supporting material: often wireframes (simple sketches of key screens) and sometimes an architecture outline describing the technical approach.
Together these are your discovery pack. It is a genuine asset: it lets you make an informed go or no-go decision, and you can take it to other suppliers for comparable quotes.
How long it takes, and what sign-off looks like
Discovery is deliberately short. For an SME project it commonly runs two to eight weeks: a simple, well-defined system sits at the short end, while anything touching several teams or older systems sits nearer the longer end. If a supplier proposes months of discovery for a modest project, ask why.
The phase ends with a clear decision point. The supplier presents the discovery pack, and you sign off the scope, the estimate and the plan before any build work is commissioned. That sign-off is the moment the project becomes real, and it should be a separate, explicit step in the contract rather than something that happens by default.
You are also free to stop. A sound discovery can conclude that the project is not worth doing, or not yet, and ending there has still saved you the far greater cost of an abandoned build.
How discovery reduces project risk
Two of the most common ways a software project goes wrong are budget overruns and scope creep, where the work quietly expands beyond what was agreed. Discovery is the main defence against both.
By pinning down the requirements and a written scope before development starts, discovery gives everyone a fixed reference point. When a new idea appears mid-project, it can be measured against the agreed scope and priced as a deliberate change, rather than absorbed unnoticed until the budget is gone.
A realistic estimate built on real requirements is also far harder to blow than a figure quoted on a hunch. Discovery is a small, predictable cost at the start that protects a much larger one later, which is why it is a standard early stage of the software development lifecycle. The international standard for software life cycle processes, ISO/IEC/IEEE 12207, places this kind of up-front planning and requirements work at the very start of any project for the same reason.
A good project starts with a good plan A clear discovery phase is the difference between a confident decision and a hopeful guess. Red Eagle Tech begins every bespoke software development engagement with discovery, so you know the scope, cost and timeline before committing to a build. If you would like to talk through an idea, the form below is the place to start.
