Discovery That Produces a Buildable Plan
Every custom software project carries risk. The budget might spiral. The finished product might not match what the business actually needs. Six months in, someone says "this isn't what we meant" and the whole thing stalls. These failures are common, expensive, and in most cases preventable.
The prevention is discovery: a short, structured investigation that happens before any code is written. Its job is to convert a vague idea ("we need a better system") into a concrete, buildable plan that everyone agrees on. Not a proposal. Not a feature list. A document that describes what will be built, why, in what order, and what it will cost.
This page explains what discovery is, what it should produce, what it typically costs, and how to tell whether a discovery phase has been done well. Whether you end up working with us or someone else, the guidance here applies.
What Discovery Actually Is
Definition: Software discovery is a time-boxed phase of investigation, typically one to two weeks, where a development team works with your business to understand your operations, map your processes, and produce a buildable plan before any commitment to a full development project.
Discovery is not requirements gathering. Requirements gathering asks "what do you want the software to do?" and writes down the answers. That is requirements elicitation in its simplest form: collecting a wish list. Discovery asks "how does your business actually work?" and then figures out what the software needs to do based on evidence, not assumptions.
The difference matters. When you ask people what they want from software, you get a wish list shaped by whatever tool they used last. When you study how the business operates (a current-state analysis, in formal terms), you uncover the real problems: the workarounds nobody mentions, the manual steps everyone has accepted as normal, the information that lives in someone's head rather than in a system.
This distinction sits at the heart of approaches like Agile Discovery, where the goal is to learn fast and validate assumptions before committing resources. It borrows from the Double Diamond model used in design thinking: first diverge to understand the problem space broadly, then converge on a specific, buildable plan. The point is not to skip ahead to a feature list. The point is to earn the right to write one.
A good discovery phase will sometimes tell you things you didn't expect. That the problem you wanted to solve with software is actually a process problem. That two departments have conflicting assumptions about how orders are handled. That the integration you assumed would be straightforward is technically complex enough to double the budget. Better to learn all of this in week one than in month six.
What Happens Without It
Projects that skip discovery follow a pattern. The development team works from a brief or a set of conversations. Assumptions fill the gaps. The quote is based on what people said they needed, not on what the business actually requires. Then reality shows up.
| Area | Without discovery | With discovery |
|---|---|---|
| Scope | Defined loosely from conversations. Gaps emerge during build. | Defined precisely from process maps and evidence. The scope document becomes the reference point for every decision. |
| Budget | Wide estimate range. Overruns feel inevitable. | Narrow budget envelope backed by documented complexity. |
| Alignment | Different people have different pictures of what's being built. | Everyone has signed off on the same document. Conflicting assumptions are resolved before they become expensive. |
| Integrations | "Just connect it to Xero" turns into weeks of unplanned work. | An integration audit surfaces complexity and costs upfront. |
| Timeline | Optimistic dates based on incomplete understanding. | Realistic phases based on mapped dependencies. |
| Scope creep | New ideas get absorbed silently. The project grows without anyone noticing until the budget is gone. | New ideas are evaluated against the agreed scope. Changes are deliberate, costed, and approved. |
The most expensive version of this pattern is building the wrong thing entirely. Not wrong because the code is bad, but wrong because nobody spent the time to understand what the business actually needed. Projects where the development is technically excellent and the client still walks away frustrated, because the software solved a problem they didn't actually have.
Discovery exists to prevent that outcome. It is the cheapest insurance you can buy against the most expensive failure mode in software development.
What a Good Discovery Produces
Discovery is only as valuable as what it delivers. A good discovery phase produces a set of tangible documents that give you everything you need to make an informed decision about whether to proceed, and on what terms. These are not vague strategy decks. They are working documents that the development team will build from.
Process maps and workflow analysis
Visual diagrams of how your business currently operates: who does what, in what order, using which tools. These expose bottlenecks, redundancies, and manual steps that software can eliminate. They also reveal where existing processes are broken and should be fixed before being automated. Tools like Miro or Lucidchart are often used for collaborative mapping sessions where your team can see the workflows take shape in real time.
System architecture and data model
A diagram showing the proposed software architecture: what the system does, how it connects to existing tools (accounting, email, CRM), and where data flows between them. This includes a data model that describes the core entities in your business (customers, orders, jobs, products) and how they relate to one another. Domain modelling at this stage prevents costly restructuring later. This is where integration complexity becomes visible and costed.
Phased roadmap
A plan that breaks the project into deliverable phases, each with its own scope, timeline, and budget range. Phase one delivers the core value. Later phases add refinements, integrations, and nice-to-haves. Priorities are typically set using a framework like MoSCoW (must have, should have, could have, won't have this time), so every feature has a clear rationale for its place in the sequence. This means you start getting value early and can adjust direction based on real usage.
Budget ranges and technical specification
Realistic cost estimates for each phase, with the reasoning behind them. Not a single number, but a narrow range that reflects the documented complexity. The technical specification sits behind the numbers: it explains the approach, the technology choices, and the effort involved in each piece of work. You will understand what drives the cost and where trade-offs exist. For context on typical UK ranges, see our guide to custom software costs.
Risk register
A list of identified risks: technical challenges, data migration difficulties, integration unknowns, organisational dependencies. Each risk has a mitigation strategy. Fewer surprises during the build because the hard questions were asked during discovery.
Gap analysis
A comparison of where the business is now (current-state) and where it needs to be (future-state design). This makes explicit what the software needs to change, what can stay as it is, and what falls outside the project scope. It ensures the team is building to close genuine gaps, not adding features that sound good but do not address real operational needs.
Some discovery phases also include wireframes or low-fidelity screen layouts to illustrate how the software will look and behave. These are not polished designs. They are conversation tools, produced in something like Figma or on a whiteboard, that help everyone agree on how the system works before a single line of code is written.
Together, these documents form a buildable plan. Not a sales document. Not a pitch deck. A plan that any competent development team could pick up and build from.
How Discovery Controls Scope and Cost
Scope creep is the silent budget killer on software projects. It accumulates one small request at a time until the project is twice as large as planned and the budget is spent. Discovery prevents this by producing a fixed reference point: the scope document. When a new idea surfaces during development (and new ideas always surface), the team evaluates it against the agreed scope. The conversation shifts from "can we add this?" to "this is outside the agreed scope. Here is what it would cost and how it would affect the timeline. Do you want to include it?" That protects both sides.
The same document solves the quoting problem. If you approach three development agencies with a verbal brief, you will get three wildly different quotes based on three different interpretations of a conversation. With a documented scope, every agency quotes against the same specification. The estimates converge to a range you can actually plan around.
A point worth making: A good discovery document is vendor-neutral. You own it. If you decide not to work with the team that produced it, you can take it to any other competent development team and get a comparable quote. Discovery gives you negotiating power, not lock-in.
When Discovery Tells You Not to Build
Sometimes the most valuable outcome of discovery is the recommendation not to build custom software at all.
This happens more often than you might expect. A business approaches a development team convinced they need a bespoke system, and discovery reveals that their actual problem could be solved by configuring an existing tool differently, connecting two systems they already own, or fixing a process that no amount of software would improve.
That is a successful discovery. The business has spent a fraction of a development budget to avoid a project that would not have delivered the value they expected. The build vs buy decision becomes clearer when you have evidence rather than instinct.
Any team that cannot tell you "don't build" when the evidence points that way is selling development hours, not advice. Discovery should be honest enough to recommend the path that serves your business, even when that path does not involve writing code.
What a Good Discovery Process Looks Like
Discovery processes vary between agencies, but the shape is broadly consistent. A well-run discovery phase typically takes one to two weeks (longer for very complex businesses with many systems) and follows a recognisable arc from understanding the problem to producing a buildable plan.
Here is the general sequence you should expect, regardless of who you work with.
Initial briefing
A senior person (ideally someone who will be involved in the actual build) leads the first conversation. They should be listening for the shape of the problem, not collecting a feature list. Expect questions about your team structure, your tools, your pain points, and your goals. Good discovery teams use a Jobs To Be Done lens at this stage: understanding what your business is trying to achieve, not just what people are requesting. If you are only speaking to a sales person at this stage, note that as a concern.
Process mapping
The team maps your existing workflows: how orders flow, how information moves between teams, where decisions get made, and where things get stuck. The best discovery teams run these as collaborative sessions, building the maps together so your team can see their own processes laid out clearly, often for the first time. This is where the workarounds that have become invisible to people who live inside them every day get surfaced and documented.
System design and feasibility
Based on the process maps, the team designs the proposed system: what it does, what it connects to, how data flows through it. This produces a system architecture and data model, assesses the technical approach, and flags any integration complexity or data migration challenges. If a proof of concept is needed to validate a risky assumption, a good team will build one during this phase rather than discovering the problem mid-project.
Roadmap and costing
The project is broken into phases, each with a clear scope, timeline, and budget range. Phase one delivers the core value. Features are prioritised using MoSCoW (or a similar framework) so you can see what is essential, what is important, and what can wait. The team should explain what drives the cost at each stage so you understand the trade-offs, not just the numbers.
Delivery and walkthrough
The team presents the complete discovery document and walks through everything together. You should leave with process maps, system design, a phased roadmap, budget ranges, and a risk register. If you leave with a slide deck and a single fixed price, something has gone wrong.
The typical cost for a discovery phase in the UK sits between £2,000 and £8,000, depending on scope and complexity. For most projects, that represents roughly 3 to 8% of the overall build budget. It is a small investment relative to the cost of getting the build wrong.
What you should prepare: Give the discovery team access to the people who do the day-to-day work (not just management), and share examples of the tools, spreadsheets, or documents your team currently relies on. The more they can see the reality of how the business runs, the better the discovery output will be.
How to Evaluate Discovery Proposals from Different Agencies
If you are getting quotes for discovery from multiple agencies (and you should, at least for your first project), you need a way to compare them meaningfully. Price alone tells you very little. A £2,000 discovery that produces a vague brief is worse value than a £6,000 discovery that gives you a buildable plan.
Here is what to look for, and what to watch out for.
Two more practical things to check. First, ask whether the discovery fee is deducted from the build cost if you proceed. Some agencies do this; others do not. Neither approach is inherently better, but it tells you something about how they view discovery (as a standalone service or as a sales cost they are absorbing). Second, ask to see an example of a previous discovery output (anonymised, of course). The quality and depth of that example will tell you more than any proposal ever could.
How to Know If Discovery Was Thorough Enough
Not all discovery phases are created equal. Some are genuine investigations. Others are lightly disguised sales exercises that produce a glossy document but leave the hard questions unanswered. Here is how to tell the difference, both during the process and after you receive the output.
During discovery
Evaluating the output
A genuine discovery phase should leave you feeling like you understand your own business better than you did before it started. The process of mapping workflows and questioning assumptions surfaces knowledge that lives in people's heads but has never been documented. Owners often realise during discovery that a task they thought took minutes actually consumes hours across the team each week. That clarity has value beyond the software project itself, and the documents are the evidence of it.
How to Know If You Need Discovery
Not every project needs a formal discovery phase. If you are adding a feature to an existing system and the scope is well understood, you probably do not need one. But if any of the following apply, discovery will save you time and money.
If you recognise yourself in two or more of those scenarios, discovery is not an optional extra. It is the most important step in the project.
Considering a discovery phase?
If you are weighing up a custom software project and want to talk through whether discovery makes sense for your situation, we are happy to have that conversation with no obligation.
Get in touch →