Software discovery phase work is the cheapest insurance a technology project will ever buy, and it is almost always the first line a nervous budget holder tries to delete. Ask two development partners to quote the same brief and the numbers can differ by a factor of five — not because one of them is dishonest, but because “we need a system to manage our jobs” is a sentence, not a specification. Each supplier has quietly filled the gaps with their own assumptions, and you are comparing two different projects that happen to share a title.
Discovery is the structured few weeks that turns that sentence into something two suppliers could price identically. It is a distinct, bounded, separately-costed engagement with its own outputs, not a long sales meeting with a better name. This guide covers what you should receive at the end of one, what it costs in the UK in 2026, how long it realistically runs, who has to be in the room, and how to tell a genuine engagement from theatre.
It also covers the outcome nobody sells you: sometimes the honest answer at the end is don’t build this. A well-run engagement that kills a bad idea for £12,000 has returned more value than one that green-lights a £250,000 build nobody uses. If you are still weighing build against buy, our breakdown of custom software development cost is the better first read, and this guide will be waiting when the answer is build.
Table of contents
- What a software discovery phase actually is
- The deliverables a software discovery phase must produce
- What a software discovery phase costs in the UK
- The software discovery phase costs that nobody invoices
- How long a software discovery phase takes
- Who needs to be in the room
- A week-by-week software discovery phase timeline
- Warning signs your discovery is going wrong
- The go or no-go decision at the end of discovery
- Software discovery phase questions UK buyers ask
What a software discovery phase actually is
The software discovery phase is the stage where you deliberately reduce uncertainty before committing serious money. You are not designing the solution yet. You are establishing what problem is actually being solved, for whom, at what scale, against which constraints, and whether software is the right instrument at all.
It is not a sales meeting with a nicer name
A supplier offering “free discovery” is offering pre-sales. That has value, but it is not the same product. Genuine discovery is paid, time-boxed and produces artefacts you own outright and could hand to a different supplier tomorrow. If the output cannot be taken elsewhere, you did not buy a software discovery phase — you sat through a pitch.
The three questions it has to answer
Every engagement worth its fee answers three things in writing. What is the measurable problem, expressed in numbers the business already tracks? What is the smallest thing we could build that moves those numbers? What could go wrong, and how much would it cost if it did? Everything else in the software discovery phase exists to support those three answers.
Where it sits in the delivery lifecycle
The UK government’s own delivery framework treats this as a formal stage, and its Service Manual guidance on how the discovery phase works is the clearest public description of the practice anywhere. Discovery precedes alpha, alpha precedes beta, and each gate is a genuine decision point. Commercial projects benefit from borrowing that discipline even when they use different vocabulary and lighter agile methodologies.
Why skipping it costs more than running it
Requirements found during a build are the expensive kind. A misunderstanding caught in a workshop costs an afternoon; the same misunderstanding caught in user acceptance testing costs a sprint, a renegotiation and a delayed launch. This is the entire economic argument for a software discovery phase, and it holds at every project size.
The deliverables a software discovery phase must produce
If you take one thing from this guide, make it this list. A proposal that does not name its outputs is not sellable work — it is a fortnight of conversations. Every software discovery phase should end with documents, not impressions.
A written problem statement with success measures
One page. What is broken, who it hurts, what it costs today, and the specific numbers that will have moved twelve months after launch — order processing time, error rate, staff hours, churn. If the sponsor cannot sign this page, nothing downstream is safe to build.
Current-state process maps
Diagrams of how the work is genuinely done today, including the spreadsheet somebody maintains at home and the workaround that exists because the last system was awkward. These maps are frequently the most valuable artefact of the whole software discovery phase, because organisations rarely have an accurate picture of their own processes.
A prioritised requirements backlog
Not a wish list. A backlog with each item sized, ranked and marked must-have, should-have or later. The ranking matters more than the sizing, because the ranking is what protects the budget when something has to give. Formal business analysis services exist precisely to produce this artefact well.
Wireframes and a clickable prototype
Enough interface to let real users react to something concrete. People cannot review a requirements document, but they can absolutely tell you that a screen is wrong. A prototype turns abstract disagreement into a five-minute conversation, and it is the deliverable that most reliably changes the scope of the eventual build.
A technical architecture and integration assessment
Which systems must this talk to, what do their APIs actually support, where does the data live, and what is the state of the data you intend to migrate? Integration optimism is the single most common cause of overrun. A software discovery phase that has not opened the legacy database has not de-risked anything.
A risk register with named owners
Ten to twenty risks, each with a likelihood, an impact, a mitigation and a person’s name against it. Vague risk registers are decoration. A useful one names the third-party API with no sandbox, the data owner who has not replied in three weeks, and the regulatory review nobody has booked.
A costed delivery plan
Finally, a phased roadmap with an estimate range — not a single number — and the assumptions each range depends on. This is the output that lets you take the software discovery phase results to a board and ask for a build budget with a straight face.
What a software discovery phase costs in the UK
Discovery is priced from the same day rates as everything else, so the arithmetic is refreshingly transparent once you know the inputs. UK consultancy and agency rates in 2026 run roughly £450 to £700 a day for a business analyst, £600 to £900 for a solution architect, and £500 to £750 for a product designer.
Small, single-process engagements: £3,000 to £8,000
One department, one workflow, no meaningful integrations. Two to three weeks of part-time effort from an analyst and a designer. This band suits an internal tool replacing a spreadsheet, and it is where most first conversations about a software discovery phase land.
Standard business applications: £8,000 to £20,000
Several user groups, two or three integrations, real data to assess. Four to six weeks with an analyst, an architect and a designer working part-time across the period. This is the most common band for UK SMEs and the one where the software discovery phase reliably pays for itself.
Complex or regulated builds: £20,000 to £45,000
Multiple departments, legacy migration, compliance review, and stakeholders in more than one country or entity. Eight to twelve weeks. Anything touching patient data, financial services regulation or safety certification belongs here, and trying to compress it is a false economy.
Enterprise programmes: £45,000 and upwards
Where discovery is itself a small project with its own governance. At this size the software discovery phase often runs in parallel workstreams and produces a business case rather than a quote.
The five to ten per cent rule
As a sanity check, discovery typically costs five to ten per cent of the eventual build. If a supplier proposes £4,000 of discovery for a project they expect to bill at £300,000, they are not planning to do the work — and if they propose £40,000 for a £60,000 build, ask what they think they are going to find.
Fixed price or time and materials
Discovery is one of the few engagements that suits a fixed price well, because the scope is the process, not the findings. Fix the fee, fix the duration, fix the deliverables list — and leave the conclusions genuinely open. A supplier who cannot fix the price of their own standard process is telling you something.
The software discovery phase costs that nobody invoices
Every proposal you receive prices the supplier’s time. None of them prices yours, and internal effort is where discovery budgets quietly overrun.
Your own team’s hours are real money
A four-week engagement typically consumes twenty to forty hours of your people’s time — workshops, interviews, prototype reviews, chasing data extracts and reading drafts. At a loaded cost of £35 to £60 an hour that is £700 to £2,400 of internal spend, landing on operational staff who still have their day jobs. Budget it explicitly rather than pretending it is free.
Decision latency costs more than the analysis
Waiting is the largest hidden cost in a software discovery phase. A sponsor who takes nine days to approve a problem statement has added nine days to a four-week programme, and on a time-and-materials engagement you are paying for the pause. Agree turnaround expectations at kick-off, in writing, with named approvers.
Somebody has to own the data extract
Almost every engagement needs a sample of real data. Getting it means a database query nobody has time to write, an export nobody feels authorised to approve, and a data protection conversation nobody scheduled. Name that owner in week one — this is the most common reason a software discovery phase slips a fortnight.
Counting internal effort changes the comparison
Once your own time is in the total, the gap between a £6,000 and a £12,000 proposal narrows considerably — and the dearer engagement often demands less of your team, because it comes with an analyst who does the chasing. Discovery that runs cheaply on your staff’s goodwill is not actually cheap.
How long a software discovery phase takes
Duration is driven by the number of people whose knowledge has to be extracted, not by the size of the eventual system. A large but simple build with two stakeholders moves faster than a small one that touches six departments.
Two to three weeks
A single team, one process, minimal integration. Realistically five to eight workshop hours plus analysis and write-up. Short engagements work well when the sponsor already has authority to decide and the process is genuinely contained.
Four to six weeks
The typical case. Multiple user groups, existing systems to inspect, and a prototype that needs at least one round of feedback. Most UK mid-market projects should budget for a software discovery phase of this length, and most that overrun did so because stakeholder diaries, not analysis, were the constraint.
Eight to twelve weeks
Regulated sectors, multi-site organisations, or migrations from systems nobody fully understands any more. Compliance sign-off has its own calendar and does not compress. Plan around it rather than hoping.
What actually makes discovery run late
Almost never the analysis. It is diary availability, a data owner on leave, a third party who will not share API documentation without a contract, and decisions bouncing back because the real decision-maker was never in the workshop. Every one of those is fixable in advance by whoever books the rooms.
Who needs to be in the room
The attendee list is the strongest predictor of whether a software discovery phase produces something usable. Get it wrong and you will produce a beautifully documented description of how a manager imagines the work happens.
The executive sponsor
Present at the start and at the end, absent in the middle. Their job is to state the business objective, confirm the budget envelope, and make the go or no-go call. A sponsor who attends every session tends to suppress the honest answers from everyone else in the room.
The people who do the work today
Non-negotiable, and the group most often left out. The person who processes the orders knows about the three exceptions that break every tidy diagram. Their input is why current-state maps in a good software discovery phase look nothing like the official procedure document.
IT and data owners
Whoever holds credentials, knows the integration history, and can say honestly how clean the legacy data is. If your organisation has no internal IT function, this is where an external technology consulting partner earns their fee during discovery rather than after it.
The supplier side
A business analyst who runs the sessions and writes the outputs, a solution architect for the technical assessment, and a designer for the prototype. On smaller engagements one person may wear two hats, but a software discovery phase run entirely by a salesperson will produce a proposal, not an analysis.
A week-by-week software discovery phase timeline
Here is what a four-week engagement looks like in practice — the shape most UK mid-market projects should expect, adjusted up or down by the bands above.
Week one: framing and alignment
Kick-off with the sponsor, agree the problem statement and the success measures, map the stakeholder list, and book every session for the remaining three weeks in one go. Getting the diaries fixed in week one is the single highest-leverage act in the entire software discovery phase.
Week two: current state
Workshops and interviews with the people who do the work. Process mapping, pain-point capture, and a first pass over the existing systems and data. Expect at least one genuine surprise; if there isn’t one, you are talking to the wrong people.
Week three: future state and prototype
Requirements workshops, backlog drafting and prioritisation, wireframes, then a clickable prototype put in front of real users before the week ends. The feedback from that session usually reshapes the backlog more than anything else in the software discovery phase.
Week four: architecture, estimate and decision
Technical assessment written up, risks registered and owned, roadmap phased, estimate ranges produced, and a readout presented to the sponsor. The engagement ends with a decision, not with a document being emailed over for someone to read later.
Warning signs your discovery is going wrong
Discovery theatre is real. It looks busy, it produces slides, and it ends with a quote that could have been written on day one.
Nobody has spoken to an end user
If every session has been with managers, you have documented an aspiration. The gap between how work is described and how it is performed is where projects go to die.
The output is a proposal, not an analysis
A readout that leads with the supplier’s recommended package, rather than with what was found, has reversed the order of the work. Findings first; recommendation second; commercials third.
The scope has not changed at all
A genuine engagement almost always changes something — a feature dropped, a phase resequenced, an integration revealed as harder than assumed. Perfect confirmation of the original brief is the least likely outcome of honest research.
No risk has an owner
An unowned risk is a sentence in a document. Ask for names and dates against each entry before you accept the pack.
Estimates arrive as a single number
Real estimates from a software discovery phase come as ranges with stated assumptions. A single confident figure this early is a marketing decision, not an engineering one.
The go or no-go decision at the end of discovery
The engagement should close with a decision meeting, and three outcomes should genuinely be on the table.
Build it
The problem is real, the measures are agreed, the scope is prioritised and the estimate is affordable. You proceed to a build phase — or, sensibly, to a first slice of one. For most organisations that first slice is best framed as MVP development services: the smallest release that proves the value in production.
Build something smaller first
The most common good outcome. Discovery reveals that sixty per cent of the value sits in twenty per cent of the scope, and the sensible move is to ship that, learn, and re-plan. The remaining backlog does not disappear; it just stops being pre-paid.
Do not build
Sometimes the finding is that the process needs fixing before any software can help, that an off-the-shelf product already does the job, or that the business case does not survive contact with the numbers. Treat this as the software discovery phase working, not failing.
Turning the outputs into a build price
Because you now hold a prioritised backlog, an architecture assessment and a risk register, the build quote stops being guesswork. Take the pack to two or three suppliers — including, if you want a regional benchmark, a software development company in Chester — and you will finally receive quotes that can be compared line by line.
Keeping discovery alive after it ends
The artefacts are living documents. Revisit the risk register at each sprint review and the success measures at each release. Treating discovery as a one-off gate, rather than a baseline you keep measuring against, wastes most of what you paid for. Our guide to how to plan a software project covers what carries forward into delivery, and formal project initiation picks up where discovery leaves off.
Software discovery phase questions UK buyers ask
Can we run discovery ourselves?
You can, if you have a practising business analyst and someone technical enough to assess integrations honestly. The common failure is internal teams documenting the current process faithfully and never challenging it. An outside facilitator is paid, in part, to ask the naive question.
Should the discovery supplier also do the build?
Often, but insist that the outputs are portable and that you are under no obligation. The healthy arrangement is one where the supplier expects to win the build on the strength of the analysis, not on your inability to take it elsewhere.
What if we already know what we want?
Then the software discovery phase will be shorter and cheaper — but run one anyway, scoped down. Certainty about the solution is not the same as clarity about the problem, and the technical and data assessment is worth the fee on its own.
Is discovery just requirements gathering?
No. Requirements gathering is one activity within it; the formal discipline of requirements elicitation assumes you already know what to elicit. Discovery also validates the problem, tests feasibility, assesses data, and can conclude that no build should happen.
How do we know it was worth the money?
Compare the pack against the brief you started with. If the scope, the sequence or the estimate changed materially, the software discovery phase paid for itself in avoided rework. If nothing changed and nothing surprised you, ask harder questions of the next supplier.
What happens if we skip straight to development?
You still do discovery — you just do it during the build, at development day rates, with a contract already signed and far less freedom to act on what you learn. That is the trade, and it is why the software discovery phase remains the highest-return few weeks in the whole delivery lifecycle.
