Software Project Discovery Phase UK: Process, Cost and Deliverables

What is a software discovery phase?

Software discovery is a focused period of research and technical planning before development begins. Its purpose is not to turn every idea into a backlog. It is to establish which problem is worth solving, who experiences it, what constraints matter, and whether software is the right response.

The principle is well established. The UK Government Service Manual recommends understanding the problem, users, constraints and value before committing to build. It also makes an important point that commercial proposals often avoid: stopping after discovery can be the correct result.

For a startup MVP, discovery might test whether the first release has a credible user and payment journey. For an established business, it may map a spreadsheet-heavy operation, inspect legacy systems and decide whether to replace, integrate or automate them.

Discovery, scoping and specification are not the same

Small projects can combine all three into one engagement. The distinction still matters: a supplier who jumps directly to features may produce a precise specification for the wrong product.

What a useful discovery process includes

1. Business goal and success measure

Start with the change the organisation needs, not a feature request. “Build an AI assistant” is a proposed solution. “Reduce the time support agents spend finding policy answers from twelve minutes to three” is a problem with a measurable outcome.

2. User and workflow research

Interview the people who perform or depend on the process. Review analytics, tickets, recordings and existing documentation. Map the complete journey, including offline work and exceptions. GOV.UK’s discovery research guidance stresses understanding how users work now and what frustrates them before planning the service.

3. Existing-system review

Inspect APIs, data ownership, authentication, hosting, vendor limits and the quality of the current code where applicable. A five-minute requirement such as “sync it with the ERP” can determine half the delivery risk.

4. Scope and priorities

Describe the smallest release that produces the intended outcome. Separate must-haves from later options and write down what is explicitly excluded. This is where a broad idea becomes an investable first release rather than a wish list.

5. Architecture and risk

Choose an approach only after the problem is understood. Record security, privacy, accessibility, integration, data-migration and operational risks. For regulated or sensitive data, discovery should identify required controls before they become expensive retrofits.

6. Delivery plan and estimate

Break the first release into milestones with assumptions and dependencies. Estimates should be ranges until the remaining uncertainty is low enough to support a fixed scope. A useful plan explains what would move the cost, not merely the number itself.

What deliverables should you receive?

• A one-page problem statement and measurable success criteria
• Primary user groups and prioritised user journeys
• A current-state process or system map
• Scope for the first release, including explicit exclusions
• Wireframes or a lightweight prototype where interaction is uncertain
• Recommended architecture and integration approach
• Data, security, accessibility and compliance considerations
• A risk and assumptions register
• A milestone-based delivery plan and budget range
• A clear recommendation to build, test further, buy an existing product or stop

Ownership matters. You should be able to take these outputs to another supplier. Discovery becomes a sales trap when the result is only a presentation and the useful detail remains inside the agency.

How long does software discovery take?

A focused SME discovery commonly takes one to three weeks. Four to eight weeks can be reasonable when a service has multiple user groups, legacy systems, complex data, regulatory constraints or several organisations involved. The Government Service Manual also describes four to eight weeks as typical for substantial public services, while noting there is no fixed duration.

A longer discovery is not automatically better. It should end when the important uncertainty has been reduced enough to make a responsible decision.

What does a discovery phase cost in the UK?

Pricing varies with the team and evidence required. As a planning range, a focused boutique-agency discovery may cost roughly £2,000–£7,500; complex work involving user research, product design, architecture and legacy analysis can reach £8,000–£25,000+. These are indicative market ranges, not a universal tariff.

Some suppliers credit discovery against a later build. That can be useful, but assess discovery on the quality and portability of its outputs. A free workshop is normally sales qualification, not a substitute for research and technical analysis.

Warning signs in a discovery proposal

• The supplier promises a technology or architecture before inspecting the problem.
• No actual users or operational staff will be involved.
• The only output is a feature list or sales presentation.
• There are no exclusions, assumptions or risks.
• The proposal guarantees an exact build cost despite unresolved integrations.
• You cannot reuse the documents with another development partner.
• Success is defined as launching, rather than improving a business or user outcome.

Can you skip discovery?

Yes, when the work is genuinely small and known: a contained bug fix, a well-documented integration your team has delivered before, or an incremental feature inside a stable product. Even then, a short written scope and acceptance criteria are sensible.

Do not skip it when you are replacing a business-critical system, handling sensitive data, introducing AI into an existing workflow, migrating legacy data, or asking several departments to change how they work. In those cases, uncertainty does not disappear when planning is removed; it simply arrives during the most expensive part of the project.

How to prepare before the first workshop

1. Write the business problem in one paragraph without naming a technology.
2. Choose a measurable outcome and record the current baseline.
3. Identify the people who use, operate and approve the process.
4. Gather analytics, support tickets, process documents and sample data.
5. List existing systems, vendors and known integration constraints.
6. State your budget boundary and any immovable deadline honestly.

This preparation shortens discovery and makes supplier proposals easier to compare. If you are still deciding what belongs in the first release, our MVP feature prioritisation guide provides a practical next step.