What a discovery phase should deliver

"Discovery" is one of the most abused words in software services. At its best it is a short, fixed-price piece of work that turns a vague ambition into a scoped and estimated plan, with the main risks already tested, that you could hand to any competent team. At its worst it is four weeks of workshops and a deck of personas nobody reads, and the invoice buys the agency time to write a proposal for the real project.

Buyers deserve a clearer standard. What follows is ours, starting with how the phase should be priced.

Why fixed price, and why paid

Discovery should be fixed price because its scope is knowable in advance. It is a defined set of activities producing a defined set of outputs. If an agency cannot fix the price of the phase whose whole purpose is to reduce uncertainty, that tells you something.

It should be paid because free discovery is a sales activity in disguise. An unpaid "scoping session" exists to win the build, and it will rarely include the unglamorous work (reading your existing codebase, trying your API, or an afternoon with your warehouse staff) that changes estimates the most. A paid phase also gives you a clean exit. If the estimate comes back at three times your budget, you have spent £15k to avoid spending £400k badly, and you own the outputs.

Typical cost, for context, is £8k to £25k depending on the size of the system, the number of stakeholders and whether a prototype is included. That is usually 3 to 8% of the eventual build.

What it should deliver

The test of every output is whether it would be useful to a different team. If the artefacts only make sense to the agency that produced them, you cannot take them anywhere else, and you should ask what you paid for.

A scoped, prioritised backlog

This is different from a feature list. It is a backlog of user-facing capabilities, each described in enough detail that an engineer could estimate it, grouped into a first release and later releases with the reasoning for where the line falls written down. It should say what is out of scope as clearly as what is in. Expect 40 to 120 items for a typical business application, and expect roughly a third of what stakeholders originally asked for to be deferred, with reasons.

A clickable prototype of the main flows

Screens for the four to eight flows that carry most of the value, wired together in Figma or a similar tool so someone can click through them. It is a test of whether the workflow makes sense to the people who will use it, and it does not need to be a visual design system. Prototypes catch the "oh, but we also need to see the previous order here" problems that cost a day to fix on paper and a fortnight in code. If a discovery phase does not put something in front of real users, it has skipped its most valuable step.

Architecture and integration decisions

A short architecture document covering the recommended stack and hosting model, the systems the new software must talk to and how, the data model at entity level, and the security and compliance constraints that shape it. Ideally as architecture decision records, one page per decision, with the options considered and the reason for the choice. This is where the agency should have inspected your existing systems (read the API documentation and tried the sandbox, ideally looked at the database too) rather than drawn boxes based on what someone said in a workshop.

An estimate given as ranges

A single figure is a guess, however confident the covering letter. A good estimate gives a range per major area (say, £38k to £55k for order management) with the assumptions that would move it to either end, and a total that admits how wide it is. Ranges of 25 to 40% at the end of discovery are normal for anything non-trivial. If someone quotes a fixed price to the pound for a nine-month build after three weeks of workshops, one of two things is true. Either they have padded it heavily, or they intend to make it back on change requests.

The estimate should also include a team shape and a timeline with the dependencies on you (content, access, decisions, user availability), because those dependencies are where most schedules slip.

A risk register you can act on

The five to fifteen things most likely to hurt the project, each with a mitigation and, where possible, a spike or proof of concept already done. "The legacy API rate-limits at 60 requests a minute, which rules out the sync approach we proposed in week one; we tested it and are recommending a nightly extract instead" is a discovery output. "Integration risk: medium" is a line in a spreadsheet.

Red flags

• No engineers in the room. If discovery is run entirely by a business analyst and a project manager, the estimate is second-hand.
• Nobody asks for access. A team that does not want to see your existing systems, data or code before estimating is estimating from folklore.
• No users interviewed. Stakeholders tell you how the process is supposed to work. Users tell you what happens on a Tuesday afternoon.
• The outputs are a deck. Slides summarise. Ask to see the backlog, the prototype and the decision records.
• A suspiciously precise number. See above.
• The scope only grew. A phase that ends with more features than it started with has not prioritised anything, and cutting is most of the job.
• The estimate matches your stated budget exactly. It can happen. Ask how they got there.

Comparing proposals

If you are running discovery with more than one agency, or comparing build proposals that follow discovery, normalise before comparing:

1. Put every proposal's scope side by side against the same backlog, because cheaper is often smaller.
2. Compare who is on the team and how experienced they are before you compare day rates. A £900-a-day senior engineer who ships in three days is cheaper than a £500-a-day junior who takes eight and needs review.
3. Look for what each proposal says about your obligations. The one that lists them has done this before.
4. Ask each agency what they would cut first if the budget were 30% smaller. The quality of that answer tells you more than the price does.
5. Check who owns the outputs. That should be you, whether or not you proceed.

How long it should take

Two to five weeks for most business applications. Two for a well-understood system with a small stakeholder group and no legacy integration; four to five for something touching multiple existing systems, regulated data or several departments with competing needs. Longer than six weeks and the phase has usually turned into unpaid design work, or it is compensating for a client who cannot make decisions. That is a problem discovery should bring into the open, and it is one the phase itself cannot fix.

Within that window, expect workshops in the first week, research and technical investigation in the middle, prototype testing and estimation in the final week, and a playback session where the outputs are walked through and challenged.

Where to start

Before you commission discovery, write a one-page brief: the problem, who has it, the systems involved, any hard constraints and a budget range. Then ask each prospective partner exactly what they will hand over at the end and what it will cost. If the answer is vague, keep looking. If you would like to see how we structure it, our process page sets out each stage and its outputs, and we are happy to talk through whether a discovery phase is even the right next step for you, since sometimes it is not.