Paying Two Agencies for Discovery Is the Cheapest Insurance You Can Buy

There is a standard way to choose a development agency, and it is not very good. You write a brief, send it to four or five firms, collect free proposals, and pick.

What that process measures is proposal quality. Proposal quality is a real skill and it is concentrated in firms with dedicated bid teams — which correlates with size and overhead, and not at all with whether the engineers who eventually show up can build your product.

There is a better approach and it costs less than people assume.

The structure

Shortlist three firms from different archetypes. Not three variations of the same thing — a full-service agency, a specialist app shop, a product engineering studio. You want genuinely different interpretations of your problem, because that variation is itself informative.

Give all three an identical brief, including your real budget range. Withholding the budget is common and counterproductive. It produces quotes calibrated to guesswork rather than to your constraints, and it wastes everyone's time including yours.

Then pay two of them for discovery. Two to three weeks, roughly £8,000 to £15,000 each.

What discovery has to deliver

This is where it succeeds or fails. A discovery phase that produces a slide deck has told you nothing.

Require three things:

A technical approach. Architecture, technology choices, and the reasoning. Not a diagram — an argument. Why this database, why cross-platform or native, how the data model handles the awkward case you mentioned.

An estimate with the assumptions stated explicitly. The assumptions matter more than the number. An estimate that says "assuming the payment provider's sandbox behaves as documented and that the existing user data is clean" is from a team that has been burned by both. An estimate with no stated assumptions is a guess wearing a suit.

A prototype of the riskiest component. Whatever you are most worried about — the integration nobody understands, the performance requirement that seems ambitious, the offline behaviour. Running code, in your repository.

That last requirement does most of the work. It is very hard to fake and it forces the team to engage with the actual problem rather than the idea of it.

What you learn that a proposal cannot tell you

Whether they engage or pattern-match. Two weeks in, you can tell whether this team has thought about your product or slotted it into a template they have used forty times.

How they communicate when something is hard. Something will be harder than expected. You get to watch how they tell you — with options attached, or not at all.

Whether they push back. A firm that accepts every requirement without challenge during a paid engagement will accept every requirement for two years, including the wrong ones.

Whether the pitch team is the delivery team. The senior architect who presents and then evaporates is the most common failure mode in this industry. Two weeks of actual work makes it immediately visible.

How they estimate. They gave you a plan for the discovery itself. Compare it to what happened. This is the single most predictive signal available and it is completely invisible in a proposal.

Who to award the build to

Here is the part that feels counterintuitive.

Award it to whoever produced the more honest discovery — which is frequently not the one with the lower number.

The firm that identified the difficult parts and priced them is usually the firm still inside budget in month five. The firm that produced a lower estimate by assuming everything goes well has not saved you money; it has moved the conversation about that money to a later date, when your leverage is worse and your options are fewer.

Signals of an honest discovery: stated assumptions, named risks, an explicit list of what is not included, and at least one place where they told you something you did not want to hear.

The objection

"Why pay two firms for work I will only use half of?"

Three answers.

You use all of it — both prototypes are real code in your repository, and both technical approaches are documents you keep. Even the losing one has validated or eliminated an approach.

The comparison is the point. A single discovery gives you an assessment. Two give you a comparison, and comparison is far more informative — you cannot tell whether an estimate is optimistic until you have another one beside it.

And set against the alternative, the cost is trivial. Choosing wrong costs you the wasted burn, the delayed launch, the restart, and the political cost of admitting it. Twenty thousand pounds against that is not really an expense.

One thing to get right

Do not run discovery on the easy part.

You are buying information, and information only has value where you are uncertain. A discovery phase that specs the login flow and the settings screen tells you nothing you did not already know.

Point it at the thing that worries you.

---

Full guide to choosing a UK app development company — 2026 cost ranges, agency archetypes, compliance requirements, portfolio red flags and contract terms: https://techcirkle.com/blog/mobile-app-development-company-uk

Frequently Asked Questions

How much should a paid discovery cost?

Roughly £8,000 to £15,000 per agency for two to three weeks. Enough to fund genuine engagement with your problem including a working prototype, and small enough that running two in parallel is clearly cheaper than choosing the wrong build partner.

What should a discovery phase actually deliver?

A technical approach with reasoning rather than diagrams, an estimate with its assumptions stated explicitly, and a running prototype of the riskiest component committed to your repository. A discovery that produces only a slide deck has not told you anything you could not have got from a proposal.

Why award the build to the more expensive discovery?

Because the firm that identified the hard parts and priced them is usually the one still inside budget in month five. A lower estimate built on assuming everything goes well has not saved money — it has deferred the conversation to a point where you have less leverage and fewer options.

Isn't running two discoveries wasteful?

You keep both outputs, including two prototypes in your own repository. More importantly, comparison is the point: a single discovery gives you an assessment, while two let you see whether an estimate is optimistic. Against the cost of choosing wrong, the spend is marginal.

Should I tell agencies my budget?

Yes. Withholding it produces quotes calibrated to guesswork rather than to your actual constraints, and it wastes time on both sides. A range is sufficient — it lets each firm propose the best version of the work that fits, which is the comparison you actually want.