How to Run a Paid Discovery Before You Commission a Build

For: A UK-based pre-Series A SaaS founder who has a development budget approved but has been burned by a previous agency that built the wrong thing after a free 'scoping call' and a vague statement of work

A paid discovery is worth commissioning only if it ends with two artefacts in your hand: a signed acceptance-criteria document and a revised fixed-price proposal that references it. Anything less — a slide deck, a Figma file, a Notion page of ‘requirements’ — is a deposit against the same scope ambiguity that burned you last time. This playbook is the buyer-side process for running one properly before you commit £60–150k to a build.

The context matters. Large IT projects run 45% over budget and deliver 56% less value than predicted, according to McKinsey and Oxford’s study of 5,400 projects. Scope creep is the top cause, hitting roughly 52% of software projects per PMI data. The discovery phase exists to move ambiguity out of the build contract and into a paid, time-boxed exercise where the cost of finding out is 1× rather than the 15× it becomes after testing or 100× after release, per NIST. You are not paying for research. You are paying for a fixed scope.

Step 1: Shortlist on discovery competence, not build portfolio

Before you commission anyone’s discovery, filter your shortlist on their ability to run one. This is a different skill from shipping code. A firm that has a delivery team but no dedicated product or solution-architect layer will run discovery as an extended sales call.

Ask each shortlisted partner three things in writing:

• Show me the acceptance-criteria document from your last three discoveries (redacted is fine). If they cannot produce one, they do not produce one.
• Who specifically will run this — name, LinkedIn, and their calendar availability for the discovery window. Not ‘a senior architect’.
• What is your revised-estimate delta on the last five projects that went through your discovery? If the answer is ‘we always come in at the original estimate’ they are either lying or padding.

The anti-pattern: shortlisting on case studies alone. A gorgeous case study for a fintech build tells you nothing about whether the same firm can define scope tightly for your workflow SaaS. The previous agency that burned you almost certainly had a strong portfolio too.

You’ll know this step is done when you have two or three firms whose discovery deliverables you have physically read, and you can name the person who will run yours at each.

Step 2: Write the discovery brief yourself — before they quote it

The single biggest mistake buyers make is asking vendors what a discovery should cover. You will get three different answers because each is optimising for their own build methodology. Write the brief yourself. It should be one page and cover:

• The decision the discovery must enable. Yours is: “Can I sign a fixed-price build contract with confidence the number will hold?” Not “understand our users better”.
• The specific ambiguities you know exist. List them. Integrations you haven’t chosen. Data model questions. Auth and multi-tenancy. Whether the AI features are actually feasible on your data volume. Compliance scope (UK GDPR is a given; is it also SOC 2 in year one?).
• The artefacts you require at the end. Named. Acceptance criteria per feature. A revised fixed-price proposal that references those criteria. A risk register with mitigations. A prioritised backlog. Architecture decision records for the choices that lock you in.
• The time box. Two to four weeks for most pre-Series A SaaS builds. Enterprise discoveries run 4–8 weeks and typically consume 3–5% of overall budget per BairesDev’s post-mortem data. If a partner proposes eight weeks for a £100k build, ask what they will do in weeks five to eight that could not happen in the build itself.

The anti-pattern: letting the vendor define the deliverables. If their proposal says “we will produce a set of user stories and a technical approach document” without defining what ‘done’ looks like on each, you have already lost.

You’ll know this step is done when your one-page brief could be handed to three vendors and they would each produce comparable proposals.

Step 3: Structure the commercial terms so discovery is a real gate

The economics only work if the discovery is genuinely optional at the end. This is where most buyers get trapped — they pay for discovery, receive something disappointing, but the sunk cost and the momentum push them into the build anyway.

Contract it explicitly:

• Fixed price for the discovery itself. Not time and materials. A vendor who cannot fixed-price a two-to-four-week scoping exercise cannot fixed-price a build either.
• No obligation to proceed. In writing. You own all outputs. This matters — if you decide to take the acceptance criteria to a different builder, you can.
• Full IP assignment on the discovery deliverables. Documents, wireframes, prototypes, architecture diagrams. No vendor lock-in through IP retention.
• The revised proposal is contractually required. Not ‘we will discuss next steps’. A specific line-item quote for the build, with a validity window (typically 30–60 days), referencing the acceptance criteria as the definition of scope.

On what discovery costs: a widely-cited industry figure is that structured discovery consumes 5–10% of overall budget upfront, and that teams who skip it spend 40–60% more on development, per Acquaint Softtech’s analysis. The number that turns this into a real quote for your project is driven by three things: how many external integrations are in scope, whether you have existing data or users to accommodate, and how much of the AI or algorithmic work is genuinely novel versus a wrapper on established models. Get those three specifics on the table before asking any partner for a discovery price.

The anti-pattern: agreeing to a discovery that is invoiced against the build if you proceed. This sounds friendly. It is not. It aligns the vendor’s incentive with getting you to proceed rather than telling you the truth.

You’ll know this step is done when your signed discovery SOW names the deliverables, the fixed fee, the IP terms, and the fact that a build engagement is a separate decision.

Step 4: Run the discovery as a working session, not a report-back

Bad discoveries look like this: the vendor disappears for three weeks and returns with a 40-page document. You read it, find it broadly reasonable, sign the build contract, and discover in week four of the build that the document glossed over three decisions that now cost £15k each to unpick.

Good discoveries look like this: two or three working sessions per week, each with a named decision on the agenda, ending with a written decision log. Your job as the buyer is to attend every session and force decisions that the team would otherwise defer.

The high-leverage sessions for a pre-Series A SaaS:

• Data model and multi-tenancy. Decisions here shape everything. If the vendor waves this away as “we’ll firm it up in build”, stop the discovery.
• Integration inventory. Every third-party system, named, with auth model, rate limits, and who owns the credentials. Ambiguity here is the single most common source of change orders.
• The ‘AI’ scoping session. If any features touch LLMs or ML, someone needs to specify prompts, models, fallbacks, evaluation criteria, and cost per transaction. ‘We’ll use GPT-4’ is not a specification. Firms with a genuine AI product practice can specify this properly.
• Non-functional requirements. Concurrent users at launch, at month six, at month eighteen. Latency budgets. Uptime target. These drive architecture choices you cannot cheaply reverse.
• Compliance scope. UK GDPR is table stakes. SOC 2? ISO 27001? PCI? This is a legal question as well as an engineering one — have your solicitor confirm what your customer contracts actually require before locking scope.

The anti-pattern: letting the vendor run discovery async and email you a document at the end. You will not catch the ambiguities from reading. You catch them from being in the room when a decision is being ducked.

You’ll know this step is done when every decision on your ambiguity list from Step 2 has a written entry in the decision log, and the log has been signed by both sides.

Step 5: Interrogate the acceptance criteria before the revised proposal is written

This is the step buyers skip and it is why they lose. Acceptance criteria drive the number. If you accept vague criteria, you accept a proposal priced against a vague scope, and change orders begin in week two of the build.

Read every criterion and ask: if the vendor built the minimum thing that satisfies this sentence literally, would I accept the invoice? If the answer is no, the criterion is not tight enough.

Examples of criteria that fail this test:

• “Users can invite team members.” — With what roles? What happens on decline? Email templates by whom? SSO in scope?
• “The system supports Stripe payments.” — Subscriptions or one-off? Which webhooks handled? Refund flow? Dunning?
• “AI generates a summary.” — Of what input length? Latency budget? What is the fallback when the model fails? Who pays the token cost at scale?

Send criteria back until they pass the literal-reading test. This is unglamorous and it is the entire point of the exercise. Softermii’s data suggests projects that complete a proper discovery achieve budget estimates within 15% accuracy, compared to 200–300% overruns on projects that skip it. That accuracy lives or dies at this step.

The anti-pattern: reviewing acceptance criteria the day before the revised proposal is due. You will not have time to force rewrites. Read them mid-discovery, not at the end.

You’ll know this step is done when you can hand the acceptance-criteria document to a technical friend who was not in the discovery, and they can tell you what the build will and will not do without asking questions.

Step 6: Compare the revised proposal against the original — and negotiate on delta, not total

The revised proposal will differ from the original in one of four ways. Each tells you something.

1. Same price, tighter scope. The vendor absorbed complexity they had missed. Reasonable. Check what came out of scope.
2. Higher price, same scope. They found genuine complexity. Ask which specific criteria drove the increase — you may be able to cut those features rather than pay.
3. Lower price. Rare, and suspicious. Usually means scope shrank in ways you have not noticed.
4. Same price, same scope. Most suspicious of all. Nothing was learned in three weeks. Do not sign.

Negotiate on the delta, line by line. “This integration went from £8k to £14k — what specifically changed?” is a better conversation than “can you knock 10% off the total?” The former surfaces reasoning. The latter just teaches the vendor to pad.

The anti-pattern: treating the revised number as the final number and negotiating headline discount. You want to negotiate scope clarity, not price.

You’ll know this step is done when you can explain every line item in the proposal to your co-founder without referring back to the vendor.

Step 7: Reference-check the discovery, not just the build

Standard reference calls ask “did they ship on time?” That is the wrong question at this stage. Ask the reference:

• How different was the final build scope from what you signed after their discovery?
• How many change orders in the build, and what triggered each?
• If you had to do it again, would you pay for their discovery? Why?
• Who ran your discovery, and are they still at the firm?

That last question matters more than people realise. The person who ran the discovery is the person who understands your scope. If they have left, institutional memory of the trade-offs left with them.

The anti-pattern: taking references only from projects that shipped successfully. Ask for a reference from a project that had scope challenges — how they were handled tells you more than smooth cases do.

You’ll know this step is done when you have spoken to at least two references who went through the same partner’s discovery, and their accounts are consistent with what the vendor told you.

What this process is bad at

Honest tradeoffs. This playbook adds two to four weeks and 5–10% of budget before build starts. If you are racing a competitor to a market window, that is real cost. If your total budget is under £30k, the overhead ratio gets uncomfortable — consider a smaller time-and-materials engagement with a trusted partner instead.

It also assumes you have the time to attend working sessions. A CEO who delegates discovery attendance to a junior product hire will get a discovery output that reflects that seniority. There is no substitute for the person signing the cheque being in the room.

Finally, it does not protect you from a partner who is technically competent but a bad cultural fit. That signal comes from the working sessions themselves — if discovery feels adversarial, the build will be worse. Walk away and eat the discovery fee. It is cheaper than the alternative.

Frequently Asked Questions

What is a paid discovery sprint in software development?

A paid discovery sprint is a fixed-price, time-boxed engagement (typically two to four weeks for a pre-Series A SaaS build) that produces a signed acceptance-criteria document, a risk register, and a revised fixed-price proposal for the build. It is distinct from a free scoping call because the output is contractually defined and the IP transfers to you. If the deliverables are not named in the SOW, it is not a discovery.

How much should a discovery phase cost relative to the build budget?

Published industry ranges put structured discovery at 3–10% of overall project budget, with BairesDev citing 3–5% for enterprise work and Acquaint Softtech citing 5–10%. The specifics that turn this into a real number for you are the count of external integrations, whether you have existing data or users to accommodate, and how novel the AI or algorithmic work is. Get those on the table before asking any partner for a discovery price.

How long should a discovery take before a £100k SaaS build?

Two to four weeks is typical for a pre-Series A SaaS at that budget. BairesDev reports enterprise discoveries running 4–8 weeks, but at £100k that upper end is usually padding. If a vendor proposes more than four weeks, ask them to justify weeks five onwards against specific decisions that cannot be made in build.

What if the revised proposal after discovery is significantly higher than the original?

That is often a sign the discovery worked, not that it failed. A vendor who priced the original against optimistic assumptions and revises upward after understanding your integrations, data, and non-functional requirements is doing you a favour compared to one who holds the number and generates change orders in the build. Interrogate the delta line by line, and be prepared to cut scope rather than absorb cost.

Can I use the discovery output with a different builder?

Only if your SOW assigns you full IP on the deliverables and permits it explicitly. This is why the commercial terms in Step 3 matter. A well-scoped discovery output — acceptance criteria, architecture decisions, integration inventory — should be portable. If a vendor resists giving you IP on discovery outputs, that is signal about how the build contract will look.

Does this process apply to AI-heavy products?

Yes, and arguably more so. AI features have a wider gap between ‘it works in a demo’ and ‘it works in production at your data volume with your latency and cost budget’. Discovery for AI-heavy builds should include specified prompts or model choices, evaluation criteria, fallback behaviour, and per-transaction cost projections — not just ‘we’ll use GPT-4’. Partners with a dedicated AI practice will insist on this; ones without will hand-wave it.