Can I use the discovery outputs with a different developer if I choose not to continue with the same agency?

Yes, and you should insist on this upfront. The specification, wireframes, and architecture documents produced in a discovery phase belong to you. A reputable agency will state this clearly in the contract. If the outputs are locked in proprietary tools or written in a way that is only actionable by that specific team, push back before signing.

How long does a software development discovery phase take?

For most UK SME projects, a discovery phase runs between one and four weeks. A tightly scoped internal tool can be properly defined in three to five working days. More complex platforms with integrations, compliance requirements, or multiple user groups will typically need two to four weeks to do properly. Be wary of discovery phases that stretch beyond six weeks without a clear reason — at that point, you are likely paying for process rather than output.

Should a discovery phase always lead into a build with the same team?

Not necessarily, though it usually makes sense. The team that ran the discovery understands the context, the constraints, and the decisions that were made along the way. Switching teams after discovery adds a handover cost. That said, if the discovery outputs are genuinely portable (as they should be), you retain the option to go elsewhere — and a good agency will be comfortable with that.

What is the difference between a discovery phase and an MVP?

A discovery phase is a research and planning process that produces documentation. An MVP (minimum viable product) is working software that real users can interact with. Discovery informs what the MVP should be. Some teams conflate the two by treating a prototype built during discovery as an MVP — this can be useful for validating assumptions early, but it is worth being clear which you are buying and what 'done' looks like for each.

Is a discovery phase worth it for a small budget project?

For a very small, tightly defined project (say, a single-workflow internal tool with a build budget under £15,000), a full formal discovery phase may not be proportionate. In those cases, a thorough written brief produced collaboratively in a single scoping session is often sufficient. For anything more complex or with a larger budget at risk, a discovery phase pays for itself by avoiding the much more expensive problem of building the wrong thing.

What Is a Software Development Discovery Phase? (And Do You Need One?)

A software development discovery phase is a structured, time-boxed piece of work that happens before any code is written. Its purpose is to define the problem clearly, agree on the scope of the solution, surface risks early, and produce artefacts (such as a specification, wireframes, or a technical architecture outline) that make the build phase significantly less likely to overrun, overspend, or miss the point. A good discovery phase typically lasts between one and four weeks and is facilitated by the people who will actually build the product.

Note

If you have been quoted a discovery phase by an agency, that quote should come with a clear list of deliverables. If it does not, ask for one before signing anything.

What Actually Happens During a Discovery Phase?

The activities vary depending on the complexity of the project, but a well-run discovery phase for a UK business will typically cover the following areas in sequence:

Problem definition: Facilitators interview stakeholders (and ideally end users) to understand the real problem being solved, not just the solution someone has already decided on. This step frequently uncovers that the initial brief was incomplete or pointed in the wrong direction.
Process mapping: The current workflow is documented, including manual steps, spreadsheet workarounds, and handoffs between people or systems. This is where operational waste becomes visible.
Requirements gathering: Functional requirements (what the system must do) and non-functional requirements (speed, security, integrations, access levels) are captured and prioritised using a framework such as MoSCoW.
Technical assessment: The existing infrastructure, data sources, and integration constraints are reviewed so that the proposed architecture fits the actual environment, not a hypothetical one.
Scope definition and estimation: Based on the above, the team produces a scoped breakdown of work with effort estimates. This becomes the foundation for a credible build-phase quote.
Risk identification: Assumptions are named, dependencies are flagged, and anything that could derail delivery is documented up front rather than discovered mid-build.
Deliverables production: The discovery concludes with tangible outputs — typically a written specification, wireframes or user journey maps, a high-level architecture diagram, and a prioritised backlog.

What Should You Actually Receive at the End?

This is the most important question to ask before paying for a discovery phase. The deliverables should be yours to keep and use with any developer, not proprietary documents that only make sense inside the agency's own process. Typical outputs from a solid discovery engagement include:

A written functional specification or product requirements document (PRD)
Wireframes or low-fidelity screen flows showing the key user journeys
A data model or entity relationship diagram if the project involves complex data
A recommended technical architecture, including stack choices and rationale
A prioritised feature backlog, usually in MoSCoW format
A scoped effort estimate for the build phase, broken down by feature area
A risk register noting open questions and dependencies

Warning

If the deliverables are locked inside a proprietary tool you cannot export, or if the specification is so vague it could only be actioned by that same agency, treat that as a red flag. You are paying for clarity, not dependency.

How Much Does a Discovery Phase Cost in the UK?

Discovery phase costs in the UK vary considerably based on project complexity and the agency or consultancy running it. As a general guide, a focused one-week scoping workshop for a straightforward internal tool might cost a few thousand pounds. A full four-week discovery covering integrations, multiple user types, and a detailed technical architecture for a more complex product can run into the tens of thousands. The right way to evaluate the cost is not against the discovery fee alone, but against the total build budget it is protecting. For a build quoted at £80,000 to £150,000, a well-run discovery phase that reduces the risk of scope creep or a costly pivot is almost always a rational investment.

Project type	Typical discovery duration	What you are buying
Simple internal tool (one workflow, one user type)	3–5 days	Scoped spec, wireframes, build estimate
Mid-complexity app (multiple integrations, several user roles)	2–3 weeks	Full spec, architecture, backlog, risk register
Complex platform (data-heavy, compliance requirements, multiple teams)	3–6 weeks	All of the above plus data model, security review, phased roadmap

Do You Actually Need a Discovery Phase?

Not every project needs a formal, paid discovery engagement. The honest answer is that it depends on how well-defined your problem already is. Here is a practical way to assess your situation:

You probably need a discovery phase if: you have a broad problem but no clear solution design; there are multiple stakeholders with different priorities; you have existing systems that need to integrate; there is regulatory or compliance context (data protection, financial services, healthcare); or you have had a previous project run over budget.
You can likely skip a formal discovery if: you have a very tightly scoped, well-understood brief with no ambiguity; you are adding a single defined feature to an existing system; or the build is small enough that a thorough scoping call and a written brief covers the same ground at no extra cost.

A trustworthy technical partner will tell you honestly which camp your project falls into. If every project an agency touches requires a paid discovery regardless of size or clarity, that is worth questioning.

The Difference Between a Discovery Phase and a Scoping Call

A scoping call is a free conversation to establish whether a project is a good fit for both parties. A discovery phase is a paid piece of work that produces real, reusable artefacts. Conflating the two is a common point of confusion. Some agencies use discovery as a label for what is really an extended sales conversation with no tangible output — avoid those. A genuine discovery phase involves preparation, structured facilitation, and documented conclusions that stand on their own without the facilitator in the room.

Red Flags to Watch For When You Are Quoted a Discovery Phase

No clear list of deliverables on the proposal
Deliverables described in vague terms such as 'alignment' or 'shared understanding' with nothing tangible
Discovery outputs that are only accessible inside the agency's own project management platform
A discovery quote that is suspiciously cheap but then feeds into an inflated build quote with no external benchmark
Pressure to begin the build immediately after discovery with no time for you to review and challenge the outputs
Discovery facilitated by a salesperson or account manager rather than the technical team doing the actual build

How Bedrock Team Approaches Pre-Build Discovery

At Bedrock Team, we run discovery as a focused, practical process facilitated by the same people who write the code. The output is a written specification and scoped estimate that you own outright, and we are explicit about what you are buying before you commit. For projects where the scope is already clear, we say so and skip the formality. If you are unsure which applies to your project, a straightforward conversation with us will give you an honest steer. Get in touch to talk through your project.