How much does a discovery phase typically cost for a UK software project?

Discovery costs vary with the complexity of the project and the seniority of the people running it. For a small internal tool, a discovery engagement might be a few thousand pounds. For a more complex platform touching multiple teams and systems, it can be higher. The meaningful comparison is not discovery fee versus zero, but discovery fee versus the cost of discovering the same problems mid-build. Ask any agency you are evaluating for a clear, fixed price for discovery before you commit.

Can I do discovery myself before approaching an agency?

You can, and it helps. Writing down your current process, listing the systems you use, and identifying your must-have requirements before a first call will make the discovery phase faster and cheaper. However, a technical partner will ask questions you have not thought to ask, particularly around data structures, integrations, and edge cases. Self-run discovery is a useful starting point, not a replacement.

What is the difference between a discovery phase and a scoping workshop?

A scoping workshop is typically a single session, often half a day or a full day, focused on defining the scope of a build. A discovery phase is broader: it includes that workshop element but also involves process mapping, stakeholder interviews, a technical audit, and documented outputs. Scoping workshops work well for simpler projects; discovery phases are more appropriate when the problem space is less defined or involves multiple stakeholders.

Should I be worried if an agency does not offer a discovery phase?

Not necessarily, but you should ask how they handle requirements definition. Some experienced teams can move quickly on well-scoped projects without a formal discovery phase. The risk is when an agency skips requirements work entirely and moves straight to a quote based on a brief conversation. That approach tends to produce either a vague contract that leads to disputes, or a significantly inflated estimate to cover the agency's uncertainty.

What happens if discovery reveals the project is bigger than expected?

This is one of the most valuable outcomes of discovery, even though it feels uncomfortable. Finding out a project is larger or more complex than expected before the build starts lets you make an informed decision: proceed with full scope, reduce scope to fit your budget, phase the build, or decide not to proceed at all. Finding that out halfway through a build, when you have already spent the budget, is a much worse position to be in.

Discovery Phase in Software Projects: What It Is and Why It Matters

A software project discovery phase is a structured, time-boxed piece of work, usually lasting one to four weeks, where a development team digs into your business problem before writing a single line of code. The output is typically a set of documented requirements, a system design or architecture outline, and a properly costed build proposal. It is paid work, and that is intentional: the people running it are spending real time on your problem, not filling in a free questionnaire.

Why Agencies Charge for Discovery

The most common reaction when a founder receives a proposal with a paid discovery phase is scepticism. Why should you pay before the actual build starts? The short answer is: because the alternative is worse. Free discovery is either rushed (a 30-minute call that produces a vague statement of work) or subsidised (the cost is quietly buried in an inflated build estimate). Neither gives you reliable information about what you are actually buying.

A paid discovery phase aligns incentives. The agency is committed to doing the work properly. You are committed to engaging seriously. Both sides arrive at the build phase with a shared, written understanding of the problem, which dramatically reduces the risk of the two most common failure modes in custom software: scope creep and misunderstood requirements.

What Actually Happens During a Discovery Phase

Discovery is not a single meeting. It is a series of structured activities designed to surface the real requirements, not the assumed ones. Here is what a well-run discovery phase typically involves:

Stakeholder interviews: The team speaks to the people who will actually use the tool, not just the person commissioning it. A warehouse manager, an ops coordinator, and a finance lead will each describe the same problem differently. All three perspectives matter.
Process mapping: Existing workflows are documented, usually as simple diagrams. This reveals where manual steps, workarounds, and data handoffs are happening, and which of those are the real source of pain.
Data and integration audit: What systems does the new tool need to talk to? What data already exists and in what shape is it? Many projects that look simple on the surface become complicated once you trace the data flows.
Requirements prioritisation: Not every requirement carries equal weight. Discovery produces a prioritised list, often split into must-have, should-have, and nice-to-have, so the build scope is defensible rather than aspirational.
Technical architecture outline: The team proposes a high-level approach: which technologies fit the problem, where the security and compliance considerations sit (particularly relevant if you handle personal data under UK GDPR), and how the system could scale.
Fixed-price build proposal: Because the scope is now defined properly, the agency can quote a build cost with real confidence. This is the document you use to make a go or no-go decision.

Tip

Ask any agency you are evaluating what you receive at the end of discovery. You should walk away with documents you own and could hand to a different developer if needed. If the answer is vague, that is a red flag.

What Discovery Is Not

Discovery is not a sales process dressed up as work. It is not a way for an agency to lock you in before you have seen any output. And it is not a guarantee that the build will go smoothly. What it does is substantially reduce the probability of expensive surprises. The distinction matters because some agencies do treat discovery as a lock-in mechanism, charging a nominal fee and then producing documents that are only useful if you continue with them. A well-run discovery phase produces genuinely portable outputs.

The Real Cost of Skipping Discovery

Many UK businesses push back on paying for discovery because they already have a clear idea of what they want. This is understandable, but there is a consistent pattern across custom software projects: what the client thinks they need at the start of a project and what they actually need once a developer starts asking specific questions are rarely identical. The gaps are usually not obvious until someone starts pulling at them.

Requirements that seemed clear turn out to have exceptions that change the architecture entirely.
An integration with an existing system turns out to require a third-party API that costs money or has rate limits.
Two stakeholders have fundamentally different mental models of how the tool should work, and no one had surfaced the conflict.
A compliance requirement (data residency, access controls, audit logging) gets discovered mid-build and forces a rework.

Each of those gaps, found mid-build rather than pre-build, costs significantly more to resolve than it would have during discovery. The cost of reworking code, resetting timelines, and managing stakeholder expectations mid-project routinely exceeds the discovery fee several times over.

How to Evaluate a Discovery Proposal

If you are comparing proposals from multiple agencies and at least one includes a paid discovery phase, here is a practical framework for assessing whether it represents good value:

What to check	Green flag	Red flag
Outputs defined upfront	Clear list of deliverables (e.g. requirements doc, architecture outline, build proposal)	Vague description like 'we will understand your needs'
Document ownership	You own everything produced, regardless of whether you proceed	Outputs are framed as internal agency documents
Who runs the sessions	A senior developer or technical lead is involved, not just a project manager	Discovery is handled entirely by a non-technical account person
Duration and effort	Time-boxed with named activities and a defined end date	Open-ended with no clear scope
Relationship to build cost	Discovery concludes with a fixed-price build proposal you can accept or decline	Discovery is presented as a deposit against future work

Is Discovery Right for Every Project?

Not always. For very small, well-defined tools (a single-screen internal form, a basic automation script), a lighter scoping conversation may be sufficient. Discovery earns its cost most clearly on projects where: the requirements span multiple teams or business processes; there are integrations with existing systems; the tool handles sensitive data; or previous attempts to solve the problem have failed. If any of those apply to your project, a proper discovery phase is almost certainly worth it.

Note

At Bedrock Team, we run discovery as a standalone, fixed-price engagement. You get a requirements document, a technical architecture outline, and a build proposal, all of which you own. There is no obligation to continue the build with us, though most clients do.