A discovery phase is the period before anyone writes production code, where the supplier works out what you actually need and what it will cost to build. It is usually paid, usually two to six weeks, and it is the part of a software engagement most likely to be skipped, rushed, or given away free as a sales tactic. All three of those outcomes cost more later.
The test of a good discovery phase is simple: if you finish it and decide not to hire the supplier who ran it, are you better off than when you started? If the answer is no, you did not buy discovery. You bought a sales process with an invoice attached.
What you should walk away with
Everything below should be handed to you as files you own, in formats you can open without the supplier’s tooling, with a written statement that the intellectual property is yours regardless of whether the build goes ahead.
- A written problem statement you recognise. Not a restatement of your brief in consultancy language. It should name the specific operational pain, who feels it, how often, and what happens today when it occurs. If you read it and think “that is not quite it”, say so before anything else proceeds.
- A scope boundary, including what is out. The out-of-scope list is more useful than the in-scope one. It is where disputes come from six months later.
- A data model or domain model. Even a rough one. The entities in your business, how they relate, which system is the source of truth for each. This is the single most portable artefact from discovery, because it survives any change of technology or supplier.
- An integration inventory. Every external system that has to be spoken to, with the specific version, authentication method, rate limits, and whether anyone has actually confirmed the API does what the documentation claims. Unverified integrations are where estimates go to die.
- A risk register with owners. Ranked, with the top three or four having a named plan. “The legacy system’s export format is undocumented” is a risk. “We will spend two days reverse-engineering a sample export in week one, and if it is worse than expected we will revisit the estimate” is a plan.
- An estimate expressed as a range, with the assumptions that produce it. More on this below.
- A first-slice recommendation. What to build first so that something real is in users’ hands early, and what that first slice proves or disproves.
Prototypes and clickable designs are common discovery outputs too, and they are genuinely useful for testing whether users understand a workflow. But treat them as a supplement, not the deliverable. A polished prototype with no data model behind it tells you how the software will look, not whether it can be built for the price quoted.
The questions a good supplier will ask you
You can judge a supplier’s competence in the first meeting by what they want to know. These are the questions that separate people who plan to build software from people who plan to sell you a proposal.
- Who decides, and who can veto? Not who the sponsor is. Who signs off, and whose objection stops the project.
- What happens today? Walk me through the current process, including the spreadsheet nobody mentions and the person who does the manual fix on Fridays.
- How will we know it worked? If the answer is “the software will be live”, that is a delivery milestone, not a measure of success.
- How much data, and how bad is it? Volume, growth rate, and quality. Migration from a messy source is frequently the largest single line in a build.
- Who runs this after launch? Your team, our team, or nobody yet. The answer changes architecture, not just the support contract.
- What compliance regime applies? UK GDPR obligations, data residency, sector rules, whether the client’s own customers impose contractual security requirements. Retrofitting an audit trail is far more expensive than designing one in.
- What is the deadline, and what is behind it? A date driven by a regulatory change or a contract renewal is real. A date driven by a board meeting is negotiable, and knowing which one you are dealing with changes what gets cut.
- What have you already tried? Failed attempts are the cheapest source of information available, and clients routinely omit them out of embarrassment.
Why an estimate without discovery is a made-up number
Software cost is dominated by things that are invisible from a brief: the shape of the existing data, the behaviour of third-party APIs under real load, the number of edge cases in a business rule that sounded simple in a meeting, and the number of people who need to approve each decision. None of these appear in a two-page requirements document. All of them can move a build by a factor of two or more.
So when a supplier gives you a firm price after one call, one of a few things is true. They have padded the number heavily, in which case you overpay for the easy case. They have priced it optimistically to win the work, in which case you will meet the change-request process. Or they intend to build something generic and reshape your requirements to fit it. The number is not a forecast; it is a negotiating position.
An honest estimate after discovery still has uncertainty in it, and says so. A range, the assumptions each end of the range depends on, and a statement of what would have to be true for the top of the range to be exceeded. If a supplier will not tell you what could make the project cost more, they have not thought about it or they do not want you to.
Red flags pointing at the supplier
- A price before any questions about your data, your integrations, or who uses the system.
- Discovery offered free. It is being paid for somewhere, usually by being shallow, and free work is deprioritised the moment a paying client needs attention.
- Discovery outputs that only make sense if you continue with them, or that are withheld until you sign the build contract.
- No named engineer involved. If discovery is run entirely by salespeople and the people who will build it never appear, the estimate carries no engineering judgement.
- Technology chosen before the problem is described.
- No risk register, or one where every risk is your responsibility.
- Reluctance to put IP ownership of the discovery outputs in writing.
Red flags pointing at the client
Discovery fails from both ends, and a supplier who never says so is not being straight with you. These are the signals that make us slow down, and if you recognise your own organisation in them it is worth fixing before you commission anything.
- Nobody can name the decision-maker. If the answer is “we will take it to the group”, the project has no owner and every design question becomes a committee.
- No access to the people who do the work. A discovery run entirely with managers describing a process they do not perform produces software for a process that does not exist.
- The budget is a secret. Withholding it does not get a better price; it gets a proposal aimed at the wrong scale entirely.
- The requirement is a solution, not a problem. “We need a mobile app” rather than “our field engineers cannot record jobs until they are back in signal”.
- Nobody will be freed up. Discovery needs perhaps a few hours a week of the right people’s time. If that cannot be committed, the build will not get it either.
- The existing system cannot be inspected. Sometimes for good reason, but the estimate then has to price the ignorance.
Before you sign the discovery contract
Ask for four things in writing: the list of deliverables you will receive, confirmation that you own them outright whatever happens next, the names of the engineers who will take part, and the price of discovery as a separate line from the build. If a supplier resists any of those, you have learned something useful for the price of an email.
And ask one more, at the end: “What did you find that you did not expect?” A discovery phase that surfaced no surprises did not look hard enough.