The Discovery Sprint Fee: How to Get Paid for the Estimate That Wins the Contract

Every agency has lost money on a fixed-bid project that was quoted from a two-page brief and a 45-minute Zoom. The fix is not better estimating skills — it's refusing to estimate for free. A paid discovery sprint turns the riskiest part of your sales cycle into a billable engagement, and it changes who is anxious in the room.

Why Free Scoping Quietly Bankrupts Agencies

The standard agency sales motion goes: intro call, requirements call, internal estimation, proposal, negotiation, contract. Somewhere between calls two and three, a senior engineer spends 8–20 hours mapping architecture, ticketing rough stories, and pricing risk. Multiply that by your close rate — often 20–30% for cold inbound — and you're paying for four unsold estimates for every signed project.

Worse, the estimates themselves are bad. You're pricing a system you've only heard described by a non-technical stakeholder who genuinely doesn't know that their "simple integration with SAP" involves three middleware layers and a vendor who takes six weeks to grant sandbox access. So you pad. If you pad too little, you eat the overrun. If you pad too much, you lose the deal to someone who padded less and will eat the overrun instead.

The discovery sprint breaks the loop. You sell a small, fixed-price engagement whose deliverable is the estimate — and along the way, a working spec that either side can walk away with.

What a Discovery Sprint Actually Is

A discovery sprint is a 1–3 week paid engagement, priced separately from the build, whose output is a package the client can use to make a go/no-go decision. It is not a workshop. It is not a strategy deck. It is billable engineering and product work with a defined artifact at the end.

A reasonable deliverable set looks like this:

• A functional spec: user stories, acceptance criteria, out-of-scope list
• A technical architecture doc: services, data model, third-party dependencies, hosting assumptions
• A risk register: unknowns, spikes needed, vendor dependencies with lead times
• A phased delivery plan with a fixed-bid range for phase one and T&M or ranged estimates for later phases
• Optional: clickable prototype for one or two critical flows

The client owns the output. If they take it to another vendor, that's their right. In practice, almost none do — you've just spent two weeks proving you understand their problem better than anyone else pitching them.

The Deliverable Is the Contract

The discovery output becomes the appendix to the build SOW. When a client later says "but I assumed X was included," you point at the out-of-scope list they signed off on. This is the single biggest reason discovery sprints reduce change-request friction — the shared vocabulary was built together, not handed down.

Pricing the Sprint

Our rough rule: a discovery sprint costs 3–8% of the projected build. If you think the build is roughly $200k, the discovery is $8k–$15k. Small enough that a director can approve it without going to procurement, large enough to fund real engineering time.

Staff it thin and senior. A typical mix:

• 1 senior engineer / tech lead (60–70% allocation)
• 1 product person or delivery lead (40–50%)
• 1 designer, only if UI prototypes are in scope (part-time)

Do not staff juniors on discovery. The whole point is that the person doing the scoping is the person who can actually smell risk. If your tech lead flags "we need a two-day spike on their auth provider," that spike happens inside the sprint, funded by the sprint, and de-risks the fixed bid that follows.

Anchor the Build Estimate to Ranges, Not Points

At the end of discovery, do not hand over a single number. Hand over a range with confidence intervals. Something like:

Phase 1 — Core booking flow
  Fixed bid: $140k – $165k
  Confidence: High (all dependencies confirmed)

Phase 2 — Partner API integrations
  Estimate: $80k – $130k
  Confidence: Medium (pending vendor sandbox access)
  Convert to fixed bid after 1-week spike

Phase 3 — Reporting & admin
  Estimate: $40k – $70k T&M
  Confidence: Low (requirements will evolve with real usage)

Clients respect this more than a single padded number, and it lets you match pricing model to actual certainty. Fixed bid where you know, T&M where you don't, spike-then-fix where you can find out cheaply.

Selling the Sprint

The objection you'll hear most is: "Your competitor is scoping this for free."

The answer is not defensive. It's this: "They are, and their estimate will be wrong, because nobody can accurately scope this system in the time they've allocated. You'll sign a fixed-bid contract and then spend six months negotiating change requests. We'd rather spend two weeks and $12k finding out what this actually costs, and give you a spec you own regardless of who builds it."

About half of prospects nod. The other half go with the free-scoping competitor and, occasionally, come back nine months later when that project is on fire. Both outcomes are fine.

A few things that raise close rates on the sprint itself:

1. Offer to credit the sprint fee against the build. If they sign the build SOW within 30 days of sprint completion, 50% of the sprint fee comes off the build invoice. This costs you almost nothing and removes the "we're paying twice" objection.
2. Cap the sprint price. Fixed fee, not T&M. The client is buying certainty, so sell certainty.
3. Name the artifacts up front. "You'll receive four documents and one prototype" is easier to buy than "we'll do discovery work."
4. Put a real kickoff date on the proposal. Sprints that start within 10 days of proposal close at meaningfully higher rates than sprints scheduled a month out.

The Conversion Metric That Matters

Track sprint-to-build conversion as its own funnel stage. In our experience, a healthy agency runs 65–80% conversion from paid discovery into signed build. Below 50% means one of three things: you're selling discovery to prospects who were never going to build, your sprint output isn't good enough to build trust, or your build pricing is out of market.

Above 90% is also suspicious — it usually means you're only selling sprints to clients who were already sold, and you're leaving qualified-but-cautious prospects on the table.

When to Skip the Sprint

Not every project needs one. Skip discovery when:

• The scope is genuinely small (under ~$40k build) and the risk of being wrong is bounded
• You've built the exact same system three times and have a productised offer
• The client is already a repeat customer and the new project is an extension
• It's a staff-augmentation or T&M engagement — nothing to fix-bid

Sprints exist to price uncertainty. If there isn't much uncertainty, don't sell one.

Handling the Handoff to Build

The worst thing you can do is run a great discovery sprint and then hand the build to a completely different team. The engineer who scoped the system needs to remain involved — either as tech lead on the build or as an architecture reviewer through phase one.

We write this into the build SOW: the discovery tech lead is named, allocated for a minimum percentage through phase one, and any substitution requires client sign-off. This costs a bit of scheduling flexibility but eliminates the "I told them X and now they're telling me Y" problem that kills trust in month two.

Where We'd Start

If you've never sold a paid discovery sprint, don't rewrite your whole sales process. Do this on your next inbound lead over $100k projected build:

1. Write a one-page discovery sprint offer. Two weeks, fixed fee at ~5% of estimated build, list the four artifacts you'll deliver.
2. Present it as the next step after the second sales call, before you've done any free estimation work.
3. If they say yes, run it seriously — senior staff, real spikes, real deliverables.
4. If they say no, thank them and move on. Do not fall back into free scoping. That's the whole point.

The first three sprints will feel awkward to sell. By the fourth, you'll wonder how you ever quoted six-figure builds off a coffee-shop conversation. If you want a second pair of eyes on your scoping process or SOW templates, our product strategy and delivery team does this work with agencies and in-house teams.