The Discovery Phase in Software Development: What You Get and When to Skip It

A software budget can go wrong before any code is written, at the moment someone prices and schedules a system that nobody has fully described yet. The discovery phase exists to close that gap. It is a short, separately scoped piece of work that turns an idea and a set of assumptions into a defined scope, a list of known risks and an estimate you can defend.

If you are commissioning custom software development from an outside team, you will almost certainly be offered one. Some discovery phases are valuable, some are padded, and some are a sales pitch with an invoice attached. This guide explains what should happen, what you should own at the end, how much effort is reasonable, and when you can shorten the phase or skip it.

What a discovery phase is

Discovery is the work of understanding the problem before committing to a solution. Nielsen Norman Group describes it as a preliminary phase that involves researching the problem space, framing the problem to be solved, and gathering enough evidence and initial direction on what to do next. The UK government's Service Manual puts it more bluntly: before you commit to building a service, you need to understand the problem that needs to be solved.

Commercial software teams use the word more loosely. In the government model, discovery is research only, and prototyping belongs to a later stage called alpha, where teams identify their riskiest assumptions and test them. Most agencies fold both into one engagement, which is fine as long as you know which activities you are paying for.

What happens during discovery

Understanding the business

The team interviews the people who will fund, use and support the system, not only the sponsor. They then map the current process step by step: who does what, in which tool, with which data, and where the delays and errors occur. This is where hidden requirements surface, such as the spreadsheet one person maintains by hand that the whole month-end close depends on.

Defining the product

From the process map, the team drafts user flows: the path each type of user takes to complete a task. The flows become a prioritized feature list, with an explicit line between what is in the first release and what is not.

Technical investigation

Engineers check the things that can quietly double a project: the systems to be integrated and whether their APIs expose what is needed, the quality and volume of data to be migrated, hosting and security constraints, and any regulatory obligations that apply to your data. Anything uncertain goes onto a risk list with an owner and a plan to resolve it.

Prototype and estimate

A clickable prototype of the main screens lets real users react before anything is built. For a genuine technical unknown, a small throwaway experiment can replace opinion with evidence. Only then does the team produce an estimate, as a range with its assumptions written down.

What you should receive and own

Discovery outputs should be useful to any competent development team, not only the one that produced them. Expect, at a minimum:

• A written summary of goals, users and success measures, in plain language
• Current and proposed process maps, plus user flows for the main tasks
• A prioritized scope, including a list of what is deliberately excluded
• Wireframes or a clickable prototype, with the editable source files
• A technical approach covering architecture, integrations, data and hosting
• A risk list and an estimate range with the assumptions behind it

Confirm in writing, before the work starts, that you own these deliverables once they are paid for and can take them to another supplier. Do not assume it. How ownership is transferred depends on the contract and on the law that governs it, which differs between the US and the UK, so have your own adviser check the wording. This article is not legal advice.

How long it takes and how much effort it involves

There is no fixed length. For public services, the UK Service Manual says there is no set time period for a discovery, but around 4 to 8 weeks is typical. That is a reference point for government services, not a rule for a commercial project, where a well-understood internal tool may need far less.

The drivers are the number of stakeholder groups, the number of systems to integrate, how well the current process is documented, whether there is regulated data, and how much of the product is new rather than a variation on something familiar. In relative terms, discovery should be a small fraction of the build, staffed by a small senior group: typically someone leading analysis, a designer and an engineer, part time.

Plan for your own effort too. Discovery fails when the client cannot make people available. Expect interviews, one or two workshops, and prompt answers from a named decision maker throughout.

How discovery narrows the estimate

The best-known model here is Steve McConnell's Cone of Uncertainty. In his Construx white paper, estimates made at the initial concept stage, even by skilled estimators, can be wrong by a factor of four in either direction. The range tightens as the product definition, the requirements and the user interface design are completed, and the paper puts the remaining variability at roughly plus or minus 25 percent once the interface design is done.

Two points from that paper matter to a buyer. First, the cone does not narrow with time or with extra effort spent on the estimate itself. It narrows only as decisions are made that remove variability, including decisions about what you will not build. Second, the cone is a best case. A discovery phase that produces documents but no decisions leaves the uncertainty where it was. Our article on custom software development cost drivers covers what moves the number once scope is settled.

When a short discovery is enough, or none at all

Discovery is proportionate risk management, not a ritual. A few days is often enough when the project is small, the process is already documented, there is one decision maker, and the integrations are standard.

You can reasonably skip a separate phase when you arrive with a current specification, tested designs and a technical lead of your own, or when the first release is so small that building it is the cheapest way to learn. Even then, ask the team to review your material and list their assumptions before quoting.

Do not skip it when the system replaces a core business process, touches several departments, depends on third-party or legacy systems, or handles sensitive data. As an illustrative scenario, imagine a distributor replacing its order spreadsheets and learning in week two of discovery that its accounting package cannot share stock levels in real time. Found at that point, it is a design decision. Found mid-build, it is a change request.

Warning signs that discovery is a sales exercise

The most common mistake buyers make is treating discovery as a formality on the way to a contract. Watch for these signs:

• The proposal lists workshops and hours but no named deliverables
• Nobody technical takes part, so integrations and data are never examined
• Your staff and end users are not interviewed, only the sponsor
• The estimate matches the budget you mentioned and has no range or assumptions
• The outputs are in a format only that supplier can use, or ownership is conditional on awarding them the build
• Nothing is ever ruled out, challenged or flagged as a risk

A sound discovery can also end with a recommendation to build less, buy an existing product, or not proceed. The Service Manual says plainly that it is not a failure to stop at the end of the discovery phase if the research points that way.

What to do next

Before asking for proposals, write one page covering the problem, the users, the systems involved and what success looks like. Name a single decision maker. Then ask each supplier the same four questions: what will you investigate, who will do the work, what exactly will I receive, and will I own it outright? Compare the answers rather than the day count.

Agree a fixed scope for the discovery itself, and treat the end of it as a real decision point. You should be free to proceed, change direction, go elsewhere or stop.

Conclusion

A discovery phase earns its place when it replaces assumptions with decisions: a defined scope, tested flows, examined integrations, a written risk list and an estimate range that is narrower because the project itself is better defined. For small, well-specified work, a brief review is enough.

Entrant Technologies builds websites, web applications, mobile apps and custom software. If you would like a view on how much discovery your project needs, you can send us an outline of your requirements and we will tell you what we would want to check before estimating it.