Why a Discovery Phase Pays for Itself, Every Time

The most expensive mistake in software

The most expensive bug in software is not a null pointer exception or a memory leak. It is building the wrong thing.

A 2024 study by the Standish Group found that 64% of features in enterprise software are rarely or never used. Not because the features are broken, but because nobody needed them in the first place. At an average development cost of £15,000–£40,000 per feature, the waste is staggering.

A discovery phase exists to eliminate this waste. It is a structured process — typically two to four weeks — where you define exactly what needs to be built, for whom, and why, before a single line of production code is written.

It is not a luxury. It is not a formality. It is the most cost-effective investment you can make in any software project. Over the past seven years, we have run discovery phases for over forty projects, and in every single case, the discovery phase paid for itself multiple times over through reduced development cost, faster delivery and better outcomes.

What a discovery phase actually involves

Discovery is not a vague "let's have some workshops" exercise. It is a structured process with concrete deliverables. Here is what a typical discovery phase looks like at Els Labs:

Week 1: Understanding the problem

We start by understanding your business, your users and the problem you are trying to solve. This involves:

• Stakeholder interviews — We talk to founders, product managers, subject matter experts and anyone who has context on the problem. We want to understand the business model, the competitive landscape and the constraints we are working within. We typically conduct three to six interviews, each lasting 60–90 minutes.

• User research — Where possible, we talk to actual users or review existing research. We want to understand their workflows, pain points and what "good" looks like from their perspective. If you do not have users yet, we work with personas based on your target market and competitive analysis.

• Existing system audit — If you have an existing product or process we are replacing, we map it out. We identify what works, what does not, and what must not break during the transition. This includes reviewing analytics data, support tickets and any technical debt that needs to be addressed.

• Competitive analysis — We review three to five competitors or analogous products. Not to copy them, but to understand market expectations, identify gaps and learn from their mistakes. This often reveals features you do not need because your competitors have already proven they do not work.

Week 2: Defining the solution

With a clear understanding of the problem, we define the solution:

• Feature mapping — We list every feature the product could include, then ruthlessly prioritise. What is essential for launch? What is important but can wait? What is nice-to-have? What should be cut entirely? This becomes your product roadmap. We use a simple MoSCoW framework (Must have, Should have, Could have, Won't have) because it forces clear decisions.

• User flows — We map the critical paths through the application. Sign up, onboarding, the core action loop, billing. Every screen, every decision point, every edge case. We focus on the three to five most important user journeys and map them in detail, including error states, empty states and edge cases.

• Technical architecture — We define the tech stack, database schema, API structure, third-party integrations and infrastructure. This is where we identify technical risks and prototype solutions for the hardest problems. If there is a technical uncertainty — can this API handle our volume? Will this architecture support our real-time requirements? — we resolve it during discovery, not during development.

• Data modelling — We design the database schema and data relationships. This forces clarity on business rules that are often ambiguous in requirements documents. What happens when a user cancels a subscription mid-billing cycle? What are the valid state transitions for an order? These questions are easier to answer with a data model in front of you than in the abstract.

Week 3: Design and validation

• Wireframes — Low-fidelity wireframes for every screen. These are fast to produce and easy to change. We iterate on these with stakeholders until the information architecture and user flows feel right. We typically produce 20–40 wireframe screens for a medium-complexity application.

• Prototype — For complex interactions, we build a clickable prototype in Figma. This lets you test the product with real users before investing in development. A prototype costs a fraction of a build and reveals usability issues that no amount of specification writing can uncover.

• Validation — We review the wireframes and prototype with stakeholders and, ideally, target users. We run lightweight usability tests — typically five users — which research consistently shows is enough to identify 85% of usability issues. We adjust based on feedback.

Week 4: Specification and planning

• Technical specification — A detailed document covering every feature, every API endpoint, every integration, every edge case. This becomes the development team's blueprint. A good specification eliminates ambiguity, which eliminates the back-and-forth that slows development down and drives up cost.

• Project plan — A timeline with milestones, deliverables and dependencies. We break the build into two-week sprints and define what ships in each one. Each milestone is a potentially shippable increment — if the project needed to stop at any milestone, you would have a working (if incomplete) product.

• Budget — A detailed cost estimate with line items for every feature. No surprises. We provide a range (optimistic to pessimistic) because honest estimation acknowledges uncertainty. The range narrows as complexity decreases — simple features have tight estimates, novel features have wider ones.

• Risk register — A list of identified risks, their likelihood, their impact and our mitigation strategies. This is not bureaucratic box-ticking — it is a practical tool for managing the inevitable surprises that every project encounters.

What a discovery deliverable looks like

At the end of a discovery phase, you receive a comprehensive deliverables package. Here is what it typically contains:

1. Executive summary (2–3 pages)

A concise overview for stakeholders who need to understand the project without reading 50 pages of specification. It covers the problem, the proposed solution, the timeline, the budget and the key risks.

2. Product specification (15–30 pages)

The detailed specification of every feature, organised by priority. Each feature includes a description, acceptance criteria, user interface notes, technical considerations and an effort estimate. This document is the single source of truth for the development team.

3. Technical architecture document (5–10 pages)

The tech stack, database schema, API design, infrastructure plan, third-party integrations and security considerations. This document ensures that the development team starts building on a solid foundation rather than making architectural decisions ad hoc.

4. Wireframes and prototype

Low-fidelity wireframes for every screen, plus a clickable Figma prototype for the key user flows. These communicate the product vision far more effectively than written specifications alone.

5. Project plan and timeline

A sprint-by-sprint breakdown of the build, with clear milestones, deliverables and dependencies. This gives you a realistic picture of when each feature will be available and where the critical path lies.

6. Budget breakdown

Line-item cost estimates for every feature, plus infrastructure costs, third-party service costs and ongoing maintenance estimates. This gives you full visibility into where your money is going.

7. Risk register

Identified risks with likelihood, impact and mitigation strategies. This is a living document that gets updated throughout the build.

At the end of discovery, you have a complete specification, a realistic timeline, an accurate budget and a prototype you can show to investors, stakeholders or users. You also have the confidence that you are building the right thing.

The ROI of discovery

It reduces total project cost by 20–40%

This is the counterintuitive truth about discovery phases: spending £5,000–£10,000 upfront typically reduces the total project cost by £20,000–£80,000.

How? Three ways:

1. Fewer change requests — Change requests during development are expensive. Changing a wireframe takes an hour. Changing a built feature takes a week. A change to the database schema after three months of development can take two weeks and affect every feature that touches the changed data. Discovery eliminates the most expensive changes by making them before development starts.

2. No wasted features — By prioritising ruthlessly during discovery, you avoid building the 64% of features that nobody uses. If your original feature list had 20 items and discovery narrows it to 12, you have just saved 40% of your development budget. Those deferred features go on the roadmap and get built later — but only if real users actually need them.

3. Fewer technical surprises — Discovery identifies technical risks upfront. That legacy API that only supports SOAP? The GDPR compliance requirement that affects your data architecture? The third-party service that has a three-week approval process? The payment provider that does not support your multi-currency requirements? You find these in week two of discovery, not week ten of development.

It accelerates delivery

Projects with a discovery phase ship faster than projects without one. This sounds paradoxical — you are adding two to four weeks before development starts. But the development phase itself is significantly faster because:

• Developers have clear specifications instead of ambiguous requirements
• Design decisions are made upfront, not debated mid-sprint
• Technical architecture is defined, so there is no thrashing between approaches
• The scope is fixed and agreed, so there is no scope creep
• Edge cases are identified and resolved, so developers do not hit unexpected complexity

A typical web application takes 12–16 weeks to build without discovery. With a four-week discovery phase, the same application takes 8–12 weeks to build. Total elapsed time is comparable, but the output quality is dramatically higher and the post-launch fix period is shorter.

It de-risks the investment

For founders and investors, a discovery phase is a risk mitigation tool. Before committing £50,000–£200,000 to a full build, you invest £5,000–£10,000 to validate the approach.

At the end of discovery, you have enough information to make a confident go/no-go decision. You might discover that the market opportunity is smaller than expected, that the technical complexity is higher than anticipated, or that there is a simpler solution to the problem. Any of these insights is worth the investment.

We have had clients who, after a discovery phase, decided not to build the product. That is not a failure — it is a success. They saved six figures by learning fast instead of building blind. One founder told us the discovery phase was the best money he ever spent, even though the conclusion was "do not build this."

It aligns stakeholders

Discovery forces alignment. Everyone in the room sees the same wireframes, reviews the same specification and agrees on the same priorities. Without discovery, different stakeholders often have different mental models of what the product will look like. These misalignments surface during development — usually as conflicting change requests — and they are expensive to resolve.

Real-world examples

The fintech platform that saved £80,000

A fintech startup came to us with a 45-feature specification for a payments platform. They had already received quotes from three agencies, ranging from £180,000 to £260,000.

During a three-week discovery phase (£7,500), we identified that 18 of the 45 features were not needed for launch and that six features could be replaced with third-party integrations at a fraction of the development cost. We also identified a critical regulatory requirement — PSD2 strong customer authentication — that none of the other agencies had flagged, which would have required a costly rearchitecture if discovered during development.

The final build cost was £95,000 — roughly half the original lowest quote. The product launched on time, passed regulatory review on the first attempt, and the deferred features were added over the following six months based on actual user feedback. Several of the deferred features were never built because user data showed they were not needed.

Total discovery investment: £7,500. Total saving: approximately £85,000 in build costs, plus the avoidance of a regulatory failure that could have cost far more.

The e-commerce rebuild that avoided disaster

An established UK retailer wanted to rebuild their e-commerce platform from Magento to a headless architecture. Their in-house team had already spent six weeks on a technical specification.

During discovery, we found three critical problems: the proposed architecture would not support their existing catalogue structure without significant data migration work (estimated at £25,000), the chosen headless CMS did not support their multi-language requirements for the EU market, and the estimated timeline was off by a factor of two because it did not account for the ERP integration complexity.

We also identified that their existing Magento site had 15,000 indexed pages with established SEO rankings. The migration plan had no provision for URL redirects, which would have destroyed their organic search traffic — worth approximately £40,000 per month in attributable revenue.

Discovery took four weeks and cost £12,000. It saved them from a £150,000 build that would have failed. The revised specification added four weeks to the timeline but produced a realistic plan that the team delivered successfully, including a comprehensive SEO migration strategy.

The SaaS MVP that shipped in half the time

A B2B SaaS startup had been building their product for four months with a freelance development team. They had spent £40,000 and were nowhere near launch. The requirements kept changing, the architecture had been rewritten twice, and the team was demoralised.

We ran a two-week discovery sprint (£5,000) that produced a clear MVP specification with 11 features (down from 34), a technical architecture, and a six-week build timeline. We identified that the core value proposition — automated compliance reporting — could be delivered with just three screens and two integrations, not the 23 screens and seven integrations in the original specification.

The product launched eight weeks later at a total additional cost of £35,000. Within three months, it had 40 paying customers. The features they cut from the MVP? They added four of them based on customer feedback. The remaining 19 were never requested.

The discovery phase did not just save money — it saved the company. They were running out of runway and needed to launch before their next fundraise. Without a clear plan and a fixed scope, they would have burned through their remaining cash without a product to show for it.

The healthcare portal that got compliance right first time

An NHS-adjacent healthcare technology company needed a patient portal with appointment booking, medical records access and secure messaging. They had a detailed specification but had not considered the regulatory requirements.

During a three-week discovery phase (£9,000), we identified that the application needed to comply with DCB0129 (clinical risk management), needed specific data handling procedures for the Data Protection Act 2018, and needed to integrate with NHS login for patient authentication. None of these were in the original specification.

More importantly, we identified that the original architecture — a standard SaaS setup with data stored in US-based cloud servers — was not compliant with NHS data sovereignty requirements. We redesigned the architecture to use UK-based Azure data centres with specific encryption and access control requirements.

The discovery phase added £9,000 and three weeks to the project. It prevented a non-compliant build that would have failed NHS Digital Assessment, costing months of rework and potentially the entire contract. The application passed assessment on the first submission.

Signs you need a discovery phase

Not every project needs formal discovery. But if any of the following apply to your project, discovery is strongly recommended:

• Your project budget is over £20,000 — The larger the investment, the higher the cost of getting it wrong. Discovery is insurance that scales with project size.

• You have multiple stakeholders with different visions — If the CEO, CTO and Head of Product each describe a different product when asked, you need discovery to align them before development starts.

• Your requirements document is more than ten pages — Long requirements documents usually contain ambiguity, contradictions and assumptions that need to be resolved before development. Discovery surfaces these issues when they are cheap to fix.

• You are entering an unfamiliar domain — If your development team does not have deep experience in your industry (healthcare, finance, logistics), discovery is where they learn the domain rules that will otherwise become expensive surprises.

• You have regulatory or compliance requirements — GDPR, FCA, NHS Digital Assessment, PCI-DSS, accessibility standards — regulatory requirements affect architecture, data handling and feature design. Discovering them mid-build is expensive.

• You are replacing an existing system — Replacement projects are deceptively complex. Users have workflows, workarounds and expectations built up over years. Discovery maps these so the new system does not break what works.

• Your last project went over budget or was delivered late — If your previous project suffered from scope creep, unclear requirements or technical surprises, a discovery phase directly addresses those root causes.

• You are not sure what you need — This sounds obvious, but it is the most common reason. If you have a business problem but not a clear technical solution, discovery is exactly what you need. It translates business goals into technical specifications.

• You are building something novel — If your product does not have close analogues in the market, discovery validates that your approach is technically feasible and commercially viable before you commit to a full build.

When you should skip discovery

Discovery is not always necessary. Here are the situations where you can move straight to building:

• You have a clear, validated specification — If you have already done extensive user research, have detailed wireframes and a technical architecture document, you do not need another discovery phase. You need a development team.

• The project is small and well-defined — A five-page marketing site, a landing page, a simple internal tool. If the scope is obvious and the technical approach is straightforward, discovery adds overhead without proportional value. As a rough guide, projects under £15,000 rarely need formal discovery.

• You are iterating on an existing product — Adding a feature to a live product with existing users and real usage data is different from building something new. You already have the context that discovery provides. A brief spike or research ticket within your sprint is usually sufficient.

• You are building a prototype — If the explicit goal is to build a throwaway prototype to test a hypothesis, skip discovery and build the quickest thing that answers your question. Discovery is for products you intend to launch and maintain.

For everything else — new products, MVPs, major rebuilds, complex integrations — a discovery phase is the best investment you can make.

How to run a good discovery phase

Involve the right people

Discovery requires decision-makers, not delegates. The people in the room need the authority to make trade-offs and set priorities. If every decision needs to go "up the chain" for approval, discovery takes twice as long and produces weaker outcomes.

At minimum, you need someone who can make product decisions (what to build), someone who can make technical decisions (how to build it) and someone who can make business decisions (what to invest). In a startup, this is often the same person. In a larger organisation, it is typically the product owner, the technical lead and a budget holder.

Be honest about constraints

Budget, timeline, technical debt, regulatory requirements, team capabilities — put everything on the table. Discovery only works when it operates on reality, not aspirations. If your budget is £50,000 and your feature list requires £150,000, we need to know that on day one, not day thirty.

The most common constraint that clients underestimate is content. Your new website or application needs content — copy, images, data — and creating that content takes time. If content is not ready when development finishes, your launch date slips. Discovery is where we identify content requirements and plan the creation timeline alongside the development timeline.

Accept that scope will change

The whole point of discovery is to refine your initial assumptions. If you come out of discovery with exactly the same specification you went in with, something went wrong. Be open to the possibility that your initial vision needs adjustment.

This is not a criticism of your idea. It is the process working as intended. Every product we have ever built changed during discovery, and every single one was better for it. The changes range from small (reordering priorities) to fundamental (pivoting the core value proposition). Both are valuable.

Choose a partner who will push back

The worst discovery partner is one who agrees with everything you say. You need a team that will challenge assumptions, question requirements and propose alternatives. You are paying for expertise, not compliance.

A good discovery partner will tell you that your ten "must-have" features include three that should be deferred. They will point out that your proposed architecture has a scaling bottleneck. They will suggest a simpler solution to the problem you are overcomplicating. This is what you are paying for.

Set clear expectations

Agree upfront on the discovery timeline, deliverables, involvement required from your team and what happens at the end. Some discovery phases result in a go decision and a seamless transition to development. Others result in a specification that you take to a different development team. Both are valid outcomes, and the expectations should be clear from the start.

Frequently asked questions

How much does a discovery phase cost?

Typically £3,000–£12,000, depending on project complexity and duration. For a straightforward web application, a two-week discovery at £5,000–£7,000 is common. For a complex platform with regulatory requirements, a four-week discovery at £8,000–£12,000 is more appropriate. As a rule of thumb, discovery costs 5–10% of the expected total project budget.

Can we do discovery ourselves?

You can, and some teams do it well. The advantage of external discovery is objectivity — an external team challenges assumptions that internal teams take for granted. The advantage of internal discovery is domain knowledge — your team knows the business better than anyone. The ideal is often a combination: internal discovery to define the problem, external discovery to validate the solution and create the technical specification.

What if the discovery phase tells us not to build?

Then it has done its job. Better to spend £5,000–£10,000 learning that the product is not viable than to spend £50,000–£200,000 building something that fails. In our experience, roughly one in ten discovery phases results in a "do not build" recommendation. The other nine result in a significantly better product than would have been built without discovery.

Does discovery lock us into using the same team for the build?

No. A good discovery deliverable is team-agnostic — any competent development team can build from it. Some clients use discovery with one partner and the build with another. Some use discovery to create a specification for an internal team. The deliverables are yours and they are useful regardless of who does the build.

How is discovery different from an audit or a consultancy engagement?

An audit examines something that already exists — a codebase, a system, a process. Discovery defines something that does not exist yet. A consultancy engagement typically produces recommendations. Discovery produces a buildable specification. The output of discovery is a blueprint, not a report.

Can we skip discovery if we have detailed wireframes already?

Wireframes are part of discovery, not a substitute for it. Wireframes define what the user sees but not how the system works, how data flows, how integrations connect, or how the architecture handles scale. If you have wireframes but not a technical specification, you still need the technical discovery work.

What happens if requirements change after discovery?

They will — and that is fine. Discovery reduces the magnitude of post-discovery changes, not the existence of them. Without discovery, you might change 40% of requirements during the build. With discovery, you typically change 5–10%. The specification is not a contract — it is a well-informed starting point.

Is a discovery phase the same as a sprint zero?

Sprint zero is a development concept that covers the technical setup for a project — repository setup, CI/CD pipelines, architecture decisions, technology evaluation. Discovery is broader: it includes user research, business analysis, feature prioritisation, wireframes and a complete specification. Think of sprint zero as the technical subset of a full discovery phase.

The bottom line

A discovery phase costs 5–10% of your total project budget. It typically saves 20–40% of your total project cost. It reduces delivery risk, accelerates development and produces better products.

There is no rational argument against running one. The only reason companies skip discovery is impatience — the desire to start building immediately. But building without a plan is not faster. It is just more expensive.

The evidence is consistent across our portfolio: projects that start with discovery deliver on time, on budget and to a higher standard than projects that skip it. The correlation is not subtle — it is the single most reliable predictor of project success that we have observed.

If you have a product idea and want to validate it before committing to a full build, start with discovery. We will tell you what it will take, what it will cost, and whether it is worth building at all.