The Discovery Sprint That Saves the Fixed-Price Bid

Every fixed-price disaster we've cleaned up — ours or somebody else's — has the same root cause. Somebody quoted a number before anyone did the thinking. The fix isn't a better spreadsheet or a padded contingency; it's a paid discovery sprint that runs before the real contract exists.

This is the version we've settled on after roughly a hundred of them. It's boring, it's structured, and it's the single highest-leverage sales motion we run.

Why the pre-sales estimate is broken

The standard agency flow looks like this: prospect sends a brief, an account lead asks a few clarifying questions, an engineer gets pulled in for a two-hour "scoping call," and then somebody produces a number with a 20% buffer. That number becomes the contract. The buffer evaporates in week three.

The problem isn't estimation skill. The problem is that you're estimating a product nobody has designed yet. The client has a shape in their head. Your engineer has a different shape. Neither shape survives contact with a real user flow, a real data model, or the third-party API that turns out to charge per seat instead of per call.

You have two options. Refuse to give a fixed price until discovery is done (most clients hate this and buy from your competitor), or run discovery as a paid, scoped engagement that produces the estimate. The second one works.

What a discovery sprint actually is

A discovery sprint is a fixed-scope, fixed-fee engagement — usually one to three weeks — whose deliverable is a document the client owns. It includes a functional spec, a technical architecture, a milestone breakdown, and a fixed-price quote for the build.

The key framing: the client is buying the plan, not a discount on the build. If they walk away with the document and hire another agency to execute, that's fine. That constraint is what forces the deliverable to be genuinely useful, not a sales artefact.

Price it so it's not free but not scary. In our experience a range of roughly 3 – 8% of the anticipated build cost works. Small enough that it's an easy "yes" for a serious buyer, big enough that tyre-kickers self-select out.

Who staffs it

Two people, sometimes three:

• A senior engineer who will also be on the build team (non-negotiable — estimators who don't ship produce fantasy numbers)
• A product designer or product lead
• Optionally, a domain specialist if the project touches payments, health data, or heavy compliance

No junior shadowing. No account manager driving the sessions. The people doing the work do the discovery.

The five-day version

Most of our discovery sprints run five working days. Longer ones just have more of the same, spread out.

Day 1: Goals and constraints

One long working session with the client's decision-makers. You are trying to answer three questions:

1. What does success look like six months after launch? (Revenue, users, internal efficiency — pick a metric.)
2. What's the hard budget ceiling and the hard date, if any?
3. What's explicitly out of scope?

Write the answers down in front of them. Get verbal agreement. This document becomes the anchor for every trade-off conversation later.

Day 2: User flows and data model

Designer runs flow mapping. Engineer starts sketching the data model in parallel. By end of day you should have:

• A list of user roles
• The primary flows for each role, at the screen-level granularity
• A first-pass entity diagram

Don't do pixel design. Wireframes are fine. The goal is to surface disagreements, not produce assets.

Day 3: Technical spikes

This is the day that pays for the whole sprint. Pick the two or three technical risks that could blow the estimate and actually try them. Not read the docs — try them.

Examples from real sprints we've run:

• Can we get the incumbent ERP to expose the fields we need via its REST API, or is it SOAP-only with a nightly export?
• Does the third-party KYC provider's sandbox actually return the response shape their docs claim?
• Does the video encoding pipeline we're planning stay under the client's per-minute cost target at realistic volumes?

A spike is not a prototype. Two to four hours per risk, timeboxed, with a written outcome:

## Spike: ERP integration feasibility
Risk: Unknown API surface, vendor claims REST but forum posts suggest SOAP.
Time spent: 3h
Outcome: Confirmed REST endpoints exist for orders and inventory.
  Customer records only available via nightly CSV drop.
Impact on estimate: +5 days for CSV ingestion pipeline,
  +ongoing cost for storage of intermediate files.
Open questions: SLA on the nightly drop — need vendor confirmation.

Every spike either shrinks the unknown or upgrades it to a known cost.

Day 4: Break down and estimate

The engineer decomposes the build into milestones. Not tickets — milestones. Each milestone should be a shippable slice worth 1 – 4 weeks of team time, with entry and exit criteria you could hand to a stranger.

Estimate each milestone as a range. Then, and only then, collapse the range into a fixed price for the contract, with the upper bound of the range as your internal target and the midpoint as the client-facing number. If the midpoint doesn't leave you with 25 – 35% gross margin after everything, the project is mispriced and you need to have that conversation now, not in month three.

Day 5: Write the document and walk it through

The deliverable is one document. Not a deck, not a Notion garden — one document the client can read in 30 minutes. Structure we use:

1. Goals and success metrics (from day 1)
2. Scope: in and out
3. User roles and flows
4. Technical architecture, one page, one diagram
5. Milestones with dates and prices
6. Assumptions and dependencies
7. Risks and how we'll handle them
8. Commercial terms for the build

Walk the client through it live. Their questions in that session are gold — they tell you exactly which parts of the estimate are fragile.

Handling the awkward moments

"Can't you just give us a ballpark now?"

Yes, but qualify it aggressively. "Projects of this shape land between £X and £3X. We can't narrow that without a week of proper work." If they push, hold. A ballpark you're forced to defend six months later is worse than a lost deal.

"We already know what we want, we just need you to build it."

Sometimes true. More often the client has a UI in their head and no data model. Offer a shorter discovery — two or three days — focused only on technical validation and estimation, skipping the flow work. Price it accordingly.

"Our internal team will do discovery, you just quote off their doc."

Red flag but not fatal. Read their document. If it's a real spec, quote off it with heavy assumptions listed. If it's a wishlist, tell them so and offer a shortened sprint to convert it. Do not accept the risk of estimating off someone else's fiction.

What this changes downstream

When a build kicks off after a real discovery sprint, three things get easier:

• Change requests become conversations, not fights. You have a document both sides signed. New requests get priced against it.
• Onboarding new engineers takes hours, not weeks. The architecture doc and milestone plan are the onboarding.
• Margin holds. Not because you padded, but because the surprises got surfaced in week zero instead of week ten.

There's a softer benefit too: the sales cycle shortens. Serious clients who've done a discovery sprint with you are dramatically more likely to sign the build contract, because they've already worked with your team and seen the output. It's the closest thing to a paid pilot that traditional services work supports.

Where we'd start

If you're running fixed-price work and don't currently sell discovery, do this next week: take your last three signed proposals, and ask honestly whether a five-day sprint before the quote would have changed the number, the scope, or the outcome. If the answer is yes on two of three, you have a business case.

Build a one-page discovery offer, price it at 5% of a typical build, and put it in front of the next prospect instead of a fixed quote. The ones who say no were going to hurt you anyway. The ones who say yes are the accounts you actually want.

We write more about how we structure agency engagements over on our services page, and there's related material on scope and pricing in the blog if you want to keep pulling the thread.