Killing the Discovery Phase: How We Scope Fixed-Bid Projects in a Week

For years our discovery phase was a paid eight-week ritual: workshops, personas, a 60-page SoW, then a contract negotiation where the client had already lost momentum. We killed it. The replacement is a five-day scoping sprint that produces a fixed-bid proposal a non-technical buyer can actually sign — and it has roughly doubled our close rate on projects between $80k and $400k.

This is the playbook, day by day, with the parts we got wrong the first three times.

Why long discovery phases keep failing

Long discoveries fail for the same reason waterfall fails: they assume you can think your way to certainty before you've touched the problem. The deliverable — usually a thick document — is optimised for covering the agency's backside, not for helping the client decide.

Three specific failure modes show up over and over:

• Scope inflation. When you have eight weeks, you fill eight weeks. Edge cases get documented as requirements. The estimate balloons.
• Stakeholder drift. The exec who signed the discovery contract gets reorged, promoted, or distracted. By week six you're presenting to someone who wasn't in the original conversation.
• The estimate gap. You priced discovery off vibes, then handed the client a build estimate 4x larger than they expected. Now you're negotiating from a defensive position.

The core insight: you don't need certainty to write a good fixed-bid. You need a bounded understanding of risk, an agreed list of what's out, and a client who trusts your process. None of that takes eight weeks.

The five-day scoping sprint

We run this as a paid engagement — usually 8–15% of the projected build cost, credited back if they sign the build contract. Paid matters. Free scoping attracts tyre-kickers and trains clients to treat your thinking as a commodity.

The team is small: one solutions architect, one senior engineer from the likely build team, and a PM who will continue into delivery. No juniors, no shadow staffing.

Day 1 — Goals and constraints, not features

Monday is a four-hour working session with the client's decision-makers. We don't ask "what do you want to build?" We ask:

• What business outcome makes this project a success 12 months after launch?
• What's the hard budget ceiling, and where did that number come from?
• What's the launch date and what's driving it?
• Who has to say yes to the contract, and are they in this room?

That last question has saved us more money than anything else in the process. If the CFO isn't bought in by Friday, we won't have a signed contract on Monday. We'd rather find out on day one.

We leave Monday with a one-page constraints sheet: budget range, deadline, must-have outcomes, and named decision-makers. Nothing about features yet.

Day 2 — Domain model and the ugly diagram

Tuesday is internal. The architect and senior engineer build a rough domain model on a whiteboard — entities, relationships, key state transitions. This is where you find the load-bearing complexity.

A payments product looks simple until you draw the reconciliation flow. A marketplace looks simple until you ask what happens to in-flight orders when a seller is suspended. The ugly diagram exposes the parts you'd otherwise underestimate by 3x.

[ User ] --places--> [ Order ] --triggers--> [ Payment ]
                        |                        |
                     [ Inventory hold ]      [ Payout schedule ]
                        |                        |
                        +---- [ Refund flow ] ---+
                                  ^
                          ( the part nobody asked about )

If the ugly diagram has more than about a dozen entities or three async flows, you're not looking at a fixed-bid project. You're looking at a phased engagement or T&M. Naming this on Tuesday is much cheaper than naming it on Friday.

Day 3 — User journeys at story-level granularity

Wednesday we walk the client through 3–5 critical user journeys. Not wireframes — narrative flows. "A new buyer signs up, browses, checks out, gets shipped a wrong item, requests a refund."

For each journey we capture the happy path and at least two failure paths. Failure paths are where fixed-bids die. "What happens if the payment provider times out mid-transaction" is a two-week feature dressed up as a footnote.

We write these as flat user stories with rough acceptance criteria. Not Gherkin, not Jira tickets. Plain English a client can read.

Day 4 — Estimation and the explicit out-of-scope list

Thursday is internal again. We estimate in three buckets per story: optimistic, realistic, pessimistic. The realistic numbers go into the proposal. The pessimistic numbers go into the contingency calculation.

Then — and this is the part most agencies skip — we write the out-of-scope list. Explicitly. "This project does not include: multi-currency, role-based admin permissions beyond admin/user, native mobile apps, SSO, accessibility audit beyond WCAG 2.1 AA spot checks."

Every out-of-scope item is a future change request you've now pre-empted. Clients don't get angry about scope changes that were named in the original contract. They get angry about surprises.

If you want more on the contract structure underneath all this, our take on pricing models goes into the trade-offs.

Day 5 — Walkthrough and signed-or-killed decision

Friday afternoon we present:

• The constraints sheet from Monday
• The domain model (cleaned up)
• The user journeys with acceptance criteria
• A fixed-bid number with a contingency band (we usually quote +15%)
• The out-of-scope list
• A delivery timeline with two or three named milestones

The client leaves Friday with everything they need to make a decision the following week. No 60-page SoW. A 12–15 page document, max.

What we got wrong the first three times

First attempt: we skipped the paid part. Conversion was fine but we burned senior time on prospects who were never going to sign. The week is intense; charging for it self-selects.

Second attempt: we let the client invite too many people. Day 1 had eleven stakeholders. Nothing got decided. We now cap it at four client-side, and we name them in the engagement letter.

Third attempt: we tried to design the UI during the sprint. Don't. UI design is a separate workstream with its own cadence. Mixing them turns Wednesday into a colour-picker debate. We commit to journey fidelity, not pixel fidelity, and price the design phase as the first sprint of the build.

When this process doesn't work

A week isn't enough for everything. We've learned to refuse the compressed sprint for:

• Regulated domains where compliance scoping (HIPAA, PCI-DSS Level 1, GDPR with cross-border data) is itself a multi-week exercise.
• Replatforms of systems with significant legacy data. Data migration scoping needs hands on the actual database, not a conversation.
• AI/ML features where you don't yet know if the model will hit the accuracy bar the product needs. You can't fixed-bid a research question.

For those, we propose a two-phase contract: a paid technical spike (typically 2–4 weeks, T&M) followed by a fixed-bid for the build once the unknowns are resolved. The spike has its own deliverable and exit criteria, so the client can stop after it if the numbers don't work.

What the contract looks like

The scoping sprint produces a proposal, not a contract. The contract itself is short — usually 6–8 pages — and references the proposal as an appendix. Key clauses we always include:

• A change request process with a flat hourly rate for changes under 16 hours and a re-scoping clause for anything bigger.
• A payment schedule tied to milestones, not calendar months. 30% on signature, then milestone-based.
• An exit clause at the first milestone. If either side wants out after milestone one, no penalty beyond work delivered. This sounds risky and almost never gets triggered, but offering it makes clients much more comfortable signing a six-figure fixed-bid.

Where we'd start

If your current discovery phase is longer than three weeks, pick the next inbound that's a reasonable fit and run a one-week sprint in parallel as an experiment. Staff it with your best people, charge for it, and compare the resulting proposal to what your normal process would have produced.

You'll find two things: the proposal is shorter, and the client decides faster. Both are wins. The third win — that your senior people get six weeks of their lives back per project — shows up in the next quarter's margins.