What Is a Software Discovery Phase and Why You Shouldn't Skip It

A software discovery phase is a short, structured period of research and planning that happens before development starts.

Its job is to answer the questions that decide whether a project will succeed: what problem you are actually solving, for whom, what the software needs to do, how it should be built, what it will realistically cost and what could go wrong. It typically ends with a clear scope, a prioritised plan and an estimate you can trust far more than a quote based on a two-page brief.

The temptation to skip it is understandable. Discovery costs money and time, produces documents rather than working software, and can feel like paying someone to tell you what you already know. Yet many of the most expensive problems in software projects, such as features nobody uses, budgets that double, timelines that slip by months and systems that cannot scale, trace back to decisions that were made too quickly at the start.

This guide explains what happens in a discovery phase, what you should receive at the end, how long it takes and roughly what it costs, when it is reasonable to keep it light and the mistakes that make discovery less useful than it should be. Whether you are commissioning a new web platform, a mobile app or a piece of internal business software, it should help you decide how much discovery your project needs.

What a discovery phase is, and what it is not

Discovery goes by several names. Agencies call it a discovery phase, scoping phase, inception, project definition or a "sprint zero". Public sector teams in the UK will recognise it from the Government Digital Service's approach, where discovery is the first of four phases (discovery, alpha, beta and live) and its purpose is to understand the problem before committing to build a solution. Whatever it is called, the core idea is the same: reduce uncertainty while it is still cheap to do so.

A good discovery phase combines three kinds of work. Business analysis clarifies goals, constraints, processes and how success will be measured. User research establishes who will use the software, what they need and how they work today. Technical analysis looks at architecture, integrations, data, security and the risks hidden in existing systems. The outputs of all three are brought together into a scope, a plan and an estimate.

It is just as important to understand what discovery is not. It is not a requirements document written by one person in isolation. It is not a sales process dressed up as consulting, where the outcome is always "build everything we proposed". And it is not a substitute for ongoing learning during development. Even with excellent discovery, teams will learn things during the build that change the plan. The aim is to remove the big, avoidable uncertainties, not to predict every detail.

It also does not always conclude that you should build. One of the most valuable outcomes of discovery is finding out that an off-the-shelf product, a smaller first release or a process change would solve the problem for a fraction of the cost. A discovery partner who never reaches that conclusion is probably not looking hard enough.

Why skipping discovery is expensive: what the evidence shows

Software projects have a long, well-documented history of running over budget and under-delivering. The causes vary, but unclear goals and requirements appear again and again.

The Standish Group, which has tracked software project outcomes for decades through its CHAOS reports, has repeatedly found that only around a third of projects are fully successful, meaning delivered on time, on budget and with satisfactory results. Its 2020 report put that figure at about 31 percent, with roughly half "challenged" and the remainder failing outright. A study of large IT projects by McKinsey and the University of Oxford found that, on average, they ran 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted. These studies define success in different ways and focus on different kinds of projects, but the overall picture is consistent: overruns are normal unless something is done to prevent them.

The Project Management Institute's research has highlighted requirements in particular. Its Pulse of the Profession work on requirements management found that inaccurate requirements gathering was among the most frequently cited causes of project failure. In product development more broadly, CB Insights' analyses of startup post-mortems have consistently ranked "no market need" among the top reasons new ventures fail. Building the wrong thing well is still failure.

Change gets more expensive as a project moves on

The reason discovery pays off is that the cost of changing your mind rises as a project progresses. Moving a feature on a whiteboard costs minutes. Changing it in a design costs hours. Changing it after it has been built, tested and connected to other parts of the system can cost weeks, and changing it after launch may involve migrating live data and retraining users.

The software engineer Barry Boehm documented this pattern decades ago, and it has been repeated in software engineering literature ever since. The exact multipliers that circulate online, such as fixes being "100 times" more expensive in production, are often quoted without reliable sources and vary a great deal by project and method. Modern agile practices have reduced the penalty for some kinds of change. The direction of the effect, though, is widely accepted, particularly for decisions about architecture, data models and integrations, which remain expensive to reverse.

Estimates are least reliable at the start

There is another, less obvious benefit. At the very beginning of a project, estimates are unavoidably rough. Steve McConnell, drawing on Boehm's work, popularised the "cone of uncertainty", which illustrates that estimates made at the initial concept stage can be off by a factor of four in either direction, narrowing only as requirements and design are clarified. A fixed quote produced before discovery is either padded heavily to cover that uncertainty or likely to be wrong. Discovery is the point where the cone narrows enough to make a sensible budget decision.

What happens during a discovery phase

Every agency and in-house team runs discovery slightly differently, and the activities should be scaled to the project. Most effective discovery phases, though, move through the same broad stages.

Aligning on goals and constraints

Discovery usually starts with workshops and interviews with the people who own the project: founders, department heads, product owners and anyone who controls budget or approval. The aim is to agree on the business goal in measurable terms, such as reducing order processing time from two days to two hours or reaching a set number of paying customers in the first year. This is also where constraints come out, including budget limits, fixed launch dates, regulatory requirements and technology the business is already committed to.

Disagreements between stakeholders often surface here for the first time. That can feel uncomfortable, but discovering that sales and operations want different things during a workshop is far cheaper than discovering it during user acceptance testing.

Understanding users and current processes

Next, the team looks at the people who will use the software and how they work today. Depending on the project, this might involve user interviews, observing staff doing their jobs, reviewing support tickets, analysing website or app data, or mapping a business process step by step. For a customer-facing product, it may include testing assumptions with potential customers before anything is built.

The output is a clear picture of user needs and pain points, often captured as personas, journey maps or process maps. These keep later decisions anchored to real people rather than internal opinions.

Assessing the technical landscape

In parallel, technical specialists examine what already exists and what the new software must connect to. That includes legacy systems, databases, third-party services, APIs, hosting and security requirements. They identify technical risks, such as an old system with no reliable API, data quality problems or performance needs that rule out certain approaches, and they often run small proofs of concept to test the riskiest assumptions.

Defining scope and priorities

With goals, user needs and technical constraints understood, the team defines what the software must do. Requirements are usually captured as user stories or features and then prioritised, commonly using a method such as MoSCoW (must have, should have, could have, won't have this time). This is where a minimum viable product or first release is defined: the smallest version that delivers real value and tests the most important assumptions.

Designing and validating the solution

Designers turn the scope into wireframes or clickable prototypes, and technical leads propose an architecture. Prototypes are tested with real users where possible. A few days of prototype testing can reveal confusing workflows or missing features that would otherwise only be discovered after development.

Planning and estimating

Finally, the team produces a delivery plan and estimate based on everything learned: phases, milestones, team composition, dependencies and risks. Good estimates at this stage are expressed as ranges with stated assumptions, not as a single precise number.

Deliverables you should expect at the end

The value of discovery lies in the decisions it enables, but those decisions need to be written down in a form you own and can use, whoever builds the software. The exact package varies by project. A thorough discovery phase usually produces most of the following.

A project vision and goals document summarises the problem, the target users, the business objectives and how success will be measured. It should be short enough that a new team member can read it in ten minutes.

User research findings capture what was learned about users and current processes, typically as personas, journey maps or process maps, with the evidence behind them.

A prioritised backlog or functional specification lists the features and requirements, usually as user stories with acceptance criteria, clearly marked by priority and by release.

Wireframes or a clickable prototype show how the main screens and workflows will work. A prototype that has been tested with users is far more valuable than one that has only been reviewed internally.

A technical architecture overview explains the proposed technology stack, hosting approach, key components, integrations and data model, with the reasons behind major choices. It should also note important non-functional requirements, such as performance, security, accessibility and compliance.

A risk register lists the main risks identified, their likelihood and impact, and how they will be managed.

A delivery roadmap and estimate sets out phases, milestones, team structure and a cost and time estimate, ideally as a range with clear assumptions.

Make sure the contract states that you own these deliverables outright. If you later decide to build with a different team, or in-house, the discovery outputs should transfer with you. A discovery package that only makes sense to the agency that wrote it has limited value.

Who is involved, how long it takes and what it costs

The discovery team

On the delivery side, a discovery team usually includes a business analyst or product manager to lead requirements and facilitate workshops, a UX or service designer to run user research and create prototypes, and a solution architect or senior developer to assess the technical side and estimate the build. Larger or more specialised projects may add a security specialist, data engineer or domain expert. A project manager or delivery lead often coordinates the work and produces the plan.

On your side, discovery needs a decision-maker who can settle disagreements and approve priorities, subject matter experts who understand the processes and users involved, and someone who knows your existing systems. Access to real users or customers makes a large difference to the quality of the outcome. The most common reason discovery runs late is not the agency. It is the client being unable to provide people, data or decisions on time.

How long discovery takes

Duration depends on complexity rather than budget alone. A focused discovery for a small web application or a single, well-understood internal tool may take one to three weeks. A discovery for a customer-facing product, a platform with several user types or a system that replaces legacy software with many integrations commonly takes four to eight weeks, and sometimes longer. Enterprise programmes with multiple departments, regulatory requirements and complex data migrations may need a longer discovery, often split into stages.

As a guide, if discovery is taking longer than the first development release it is meant to plan, the scope of discovery itself may be too broad.

What discovery costs

Discovery is usually priced as a fixed fee or a short time-and-materials engagement, based on the size of the team and the number of weeks. Because rates and scope vary so widely between agencies and countries, there is no reliable industry average. What can be said is that a well-run discovery phase usually costs a small fraction of the build it informs, and that the cost should be judged against the risk it removes. Spending a few weeks' budget to avoid building the wrong features, choosing the wrong architecture or committing to an unrealistic quote is usually a sound trade.

Some agencies offer free or heavily discounted discovery as part of the sales process. Be cautious. Free discovery tends to be shallow, and it creates pressure to continue with the same supplier. A paid discovery with deliverables you own gives you a genuine choice about what happens next.

When discovery can be shortened, and when it must not be

The title of this guide says you should not skip discovery, and that is true for almost every meaningful software project. It does not mean every project needs the same amount. The right depth depends on how much uncertainty you are carrying.

A lighter discovery is reasonable when the problem is narrow and well understood, when you are extending an existing product your team knows well, when a working prototype or detailed specification already exists and has been tested with users, or when the project is a small, low-risk tool where the cost of getting something wrong is limited. In these cases, a few focused workshops, a technical review and a short scoping document may be enough.

A thorough discovery is essential when the stakes or the unknowns are high. That includes new products where demand has not been proven, systems that replace business-critical or legacy software, projects with several departments or user groups whose needs may conflict, work involving sensitive data, payments or regulation, and projects that depend on complex integrations with systems you do not control. It also matters when the budget is fixed and significant, because those are the projects where an inaccurate estimate does the most damage.

A useful test is to write down the three assumptions that, if wrong, would most damage the project. If you can confidently back each one with evidence, discovery can be light. If you cannot, those assumptions are exactly what discovery should test.

Common discovery mistakes

Discovery is only as useful as the way it is run. These are the problems that most often turn it into an expensive formality.

Treating it as a documentation exercise. A long specification that nobody reads is not the goal. The goal is shared understanding and confident decisions. If key stakeholders have not engaged with the outputs, the documents will not prevent problems.

Talking only to managers. Senior people often describe how a process should work, not how it actually works. The staff who do the work every day, and the customers who use the product, frequently reveal requirements and frustrations that never come up in leadership workshops.

Deciding the solution before the research. When a team arrives with the answer already fixed, such as "we need a mobile app" or "we need to rebuild the platform in a new framework", discovery becomes a search for supporting evidence. Keep the problem open long enough to consider alternatives, including not building anything at all.

Gold-plating the scope. Discovery often uncovers many good ideas. Without strict prioritisation, they all end up in the first release, and the budget grows to match. A clear definition of the first valuable release is one of the most important outputs.

Ignoring non-functional requirements. Performance, security, accessibility, data protection and scalability are easy to overlook in workshops focused on features. They have a large effect on architecture and cost, so they belong in discovery.

Treating the estimate as fixed for ever. Discovery dramatically improves the estimate, but it does not eliminate uncertainty. Agree how changes will be handled during development, and revisit the plan regularly as the team learns.

Losing momentum afterwards. A long gap between discovery and development lets knowledge fade and circumstances change. Plan the start of development, or at least the next decision point, before discovery finishes.

Getting the most from a discovery engagement

If you are commissioning discovery from an agency or consultancy, a little preparation makes the investment go much further.

Prepare before it starts

Gather what you already have: existing documents, process descriptions, analytics, customer feedback, support data, screenshots of current systems and any previous attempts at specifications. Write a short brief describing the problem, the goals and what you believe the main constraints are. Identify the people who need to be involved and book their time in advance, because diaries are usually the biggest bottleneck.

Ask the right questions of potential partners

When comparing discovery proposals, ask what exactly you will receive at the end, and request an anonymised example of a past discovery output. Ask who will be on the team and how much of their time is allocated, since a discovery led mainly by sales staff will not produce a reliable technical plan. Ask how they involve real users, how they handle disagreement among stakeholders and whether they have ever recommended that a client not build something. Finally, confirm that you will own the outputs and are free to take them to another supplier.

Stay closely involved

The best discovery phases feel collaborative. Attend workshop playbacks, review findings as they emerge rather than waiting for the final report, and challenge assumptions you disagree with. Your knowledge of the business is half of the input. A discovery that happens to you, rather than with you, rarely captures it fully.

Use the outputs to make a real decision

At the end of discovery, you should be able to make an informed go or no-go decision, choose between options with a clear understanding of trade-offs and set a realistic budget. If the outputs leave you unable to do that, ask for the gaps to be filled before moving into development.

For businesses planning a new website, platform or piece of custom software, a well-run discovery phase is one of the most reliable ways to protect the budget and improve the outcome. An experienced development partner should be able to explain exactly how their discovery works, what it costs and how it connects to delivery, without pressuring you to commit to the build in advance. (Internal link suggestion: a software or web development services page, or a guide to estimating software development costs.)