What a discovery phase should give you before a big software build

A discovery phase should give you a written plan you can act on: a clear statement of the problem, who the users are and how they work, where the data lives, a sketch of the system, the main risks, a phased plan and rough estimate ranges for each phase. It saves money on large projects because it moves the expensive surprises to the point where they cost the least to fix, which is before anyone writes production code. If a discovery phase ends without those documents in your hands, it was a sales process, not discovery.

At VC Media, this is the first of our three steps, which we call Map it. The other two are Build it and Run it. This article explains what good discovery looks like, whoever you hire for it.

What is a discovery phase?

Discovery is a short, focused piece of work before a build. The team that will design the system spends time with the people who will use it, looks at the systems and data you already have, and works out what should be built first and why.

It is different from a sales call or a proposal. A proposal is written to win the work. Discovery is done to understand it, and its output should be useful to you even if you never build anything.

It goes by several names: discovery, scoping, a planning phase, a technical assessment. The name matters less than what you get at the end.

Why does discovery save money on large projects?

Large software projects rarely go wrong because the code was hard to write. They go wrong because the team built the wrong thing, missed a data source, misunderstood a workflow or found a hard constraint late.

Each of those is cheap to fix on paper and expensive to fix in software. Changing a sentence in a plan takes minutes. Changing a database structure after three screens and two integrations depend on it can take a long time and break things that already worked.

Discovery also protects your budget in less obvious ways:

• It splits the project into phases, so you can stop, adjust or change direction after each one instead of committing to everything at once.
• It makes estimates honest. An estimate based on a real map of your systems is far more reliable than one based on a first meeting.
• It surfaces the decisions only you can make, such as which team’s workflow wins when two teams do the same job differently.

What should a discovery phase deliver?

These are the deliverables we think every serious discovery should produce. The format can vary. Their existence should not.

1. A problem statement. One or two paragraphs on what is wrong today, who it affects and what will be different when it is fixed. If the team cannot write this clearly, they do not understand the project yet.

2. Users and workflows. Who will use the system, what each type of user is trying to get done, and the steps they follow today. This is often drawn as a simple diagram per workflow. It is where most hidden requirements come out.

3. A data sources map. Every system that holds data the project needs: the CRM (customer relationship management software), the booking or order system, spreadsheets, third-party feeds. For each one, what data it holds, who owns it, how it can be accessed and how reliable it is. On data and dashboard projects, this map is often the most valuable single page. Our guide to what a data platform is explains why.

4. An architecture sketch. A diagram of how the parts of the new system fit together: where data comes in, where it is stored, what processes it and what people see. It does not need every detail. It needs enough that another engineer could look at it and understand the approach.

5. Risks and unknowns. What could stop the project or make it much harder. A system with no API (a way for other software to read its data), data that is messier than people think, a dependency on one person’s knowledge, a compliance rule. Each risk should come with a way to reduce it or test it early.

6. A phased plan. The project broken into stages, each delivering something usable. The first phase should be small enough to prove the approach and valuable enough to matter on its own.

7. Rough estimate ranges in words. Not a fixed quote, but a sense of relative size: which phases are small, which are large, and where the uncertainty sits. A range that is wide because of a named unknown is more honest than a precise figure that ignores it.

Good discovery also ends with a short list of decisions you need to make before the build starts, and a recommendation on each.

How long should discovery take?

Short compared with the build. Discovery should be a small part of the overall project, not a project of its own. If it starts to rival the build in length, scope has crept or the team is hedging.

How long it runs depends mainly on the number of systems involved and the number of teams who use them. A project that pulls from one database for one team needs little discovery. A platform that connects many systems used by several departments needs more, because the data sources map and the workflows take longer to get right.

It should also have a defined end and a defined output agreed before it starts. Open-ended discovery is a warning sign.

Who should be involved from your side?

Discovery only works if the people who know the business take part. Plan for:

• A decision maker who can settle priorities and trade-offs.
• The people who do the work today, not only their managers. They know the workarounds.
• Whoever looks after your current systems, internal or external, who can grant access and explain quirks.

Expect to spend real time in workshops and interviews early on, then less as the team writes things up.

Red flags

Watch for these:

• Discovery with no deliverables. A series of friendly meetings that ends with a quote and nothing written down. You have paid for a sales process.
• Discovery skipped entirely. A team that offers a fixed price for a large, unclear project after one meeting is either padding the price heavily or planning to find the problems later, at your expense.
• Deliverables you cannot keep. The plan should belong to you, not stay locked in the vendor’s tools.
• No one talks to the users. Discovery done only with senior managers misses how the work actually happens.
• Every risk is minor. Real projects have real risks. A list with nothing serious on it was not looked at closely.
• The plan is one big phase. If nothing usable arrives until the very end, you carry all the risk until then.

How to use the output even if you change vendors

Good discovery output is portable. Any competent team should be able to pick it up and build from it. That gives you options:

• Get competing quotes on the same plan. Bidders then price the same scope, which makes quotes comparable.
• Hand it to your in-house team if you decide to build internally. Our article on choosing a consultant, agency or in-house team covers that decision.
• Use it to decide whether to build at all. Sometimes discovery shows that a well-chosen product plus some integration does the job. Our guide to building or buying software helps there.
• Keep it as the project’s reference. Update the architecture sketch and data map as the system changes, and they stay useful for years.

If a vendor resists handing over discovery documents in an editable form, ask why.

Where to start

Before you speak to any vendor, write half a page: the problem in your own words, who it affects, and every system you think holds data the project needs. That is the seed of the problem statement and the data sources map, and it will make any discovery conversation faster and sharper. If your project involves bringing data together into dashboards or adding AI to how your team works, our dashboards and data platforms and AI integration pages explain how we approach it. When you are ready, send us your half page and we will tell you what discovery would need to cover.

Questions people ask

What is a discovery phase in software development?

A discovery phase is a short, paid stretch of work before a build where the team learns the business, maps the users, workflows and data, and produces a plan. It ends with written deliverables you can use to decide whether, how and with whom to build.

What should a software discovery phase deliver?

At minimum, a problem statement, a description of the users and their workflows, a map of data sources, an architecture sketch, a list of risks, a phased plan and rough estimate ranges. Each should be written down and yours to keep.

Is a discovery phase worth paying for?

On a large or unclear project, usually yes, because it is far cheaper to change a plan on paper than to change software that is half built. On a small, well-understood project, a short conversation and a written scope may be enough.