The Fixed-Price Escape Hatch: How to Quote a Milestone Contract Without Losing Your Shirt

Fixed price is the contract shape clients want and the one agencies fear. The fear is rational: you're quoting a number against a document you wrote in a week about a problem the client hasn't fully described. But refusing fixed price entirely costs you deals, and time-and-materials has its own failure modes. The middle path is a milestone contract with explicit escape hatches — the clauses that let you re-baseline without going to war.

Here's how we structure them, and the traps we've walked into ourselves.

Why Pure Fixed Price Fails

A pure fixed-price contract assumes three things that are almost never true on custom software:

1. The scope is fully known at signature.
2. The client's team will respond to questions on time.
3. No external dependency (a third-party API, a legal review, a design sign-off) will slip.

When any of these break — and one always does — the agency absorbs the cost. You end up in a silent argument where the PM is trying to shrink acceptance criteria and the client is trying to expand them. Nobody wins, and the retro is bitter.

T&M solves this by transferring risk to the client, which is fair but often unsellable. Procurement wants a number. Founders raising a seed round want a number. The number is what gets the PO cut.

Milestone contracts with escape hatches let you give them a number without pretending you have a crystal ball.

The Anatomy of a Milestone Contract That Survives

A milestone contract breaks the project into 3 – 6 chunks, each with its own fixed price, its own acceptance criteria, and — critically — its own re-baseline point. The client pays per milestone. Either side can renegotiate scope or walk between milestones without breach.

We use four building blocks in every SOW:

1. The Assumption Register

Every fixed price is built on assumptions. Most SOWs bury them in a paragraph nobody reads. Pull them out into a numbered table at the top of the document:

| # | Assumption | If false, impact |
|---|-----------|------------------|
| A1 | Client provides Figma designs by milestone kickoff | +2 weeks, +design fee |
| A2 | Auth handled via existing Auth0 tenant | +1 week to build custom |
| A3 | Payments limited to Stripe (no PayPal/wallets) | Change request |
| A4 | Client QA responds to bug tickets within 2 business days | Milestone date slips 1:1 |

When an assumption breaks, you don't argue about whether it's scope creep. You point at row A2 and open a change request. The register does the negotiating for you.

2. The Re-Baseline Trigger

Somewhere in the middle of every project, reality diverges from the plan. The re-baseline trigger is a contractual moment — usually after the discovery or design milestone — where both sides agree to re-quote the remaining work based on what's actually been learned.

We write it like this:

After Milestone 2 (Design & Technical Specification), both parties will review the remaining scope. If estimated effort for Milestones 3 – 5 has changed by more than 15% in either direction, revised pricing will be issued. Client may accept, negotiate, or terminate with payment only for completed milestones.

This clause has saved us more money than any other single sentence in our contracts. It reframes the awkward "we underestimated" conversation as a scheduled, contractual event. Nobody feels ambushed.

3. The Milestone Exit

Clients get twitchy about being locked in. Agencies get twitchy about being ghosted mid-build. A milestone exit clause makes both sides safer:

Either party may terminate at the end of any completed milestone with 10 days written notice. Fees for completed milestones are non-refundable. Work in progress at the time of notice will be invoiced at the T&M rate through the notice period.

Counter-intuitively, offering an exit makes clients less likely to use it. What kills deals is the fear of being trapped in a bad contract. Remove that fear and they'll stay through friction they otherwise would've bailed on.

4. The Definition of Done, Per Milestone

"Done" is where fixed-price contracts go to die. If your acceptance criteria say "functional checkout flow", you'll spend three weeks arguing about whether guest checkout counts. Write acceptance criteria as testable statements:

• User can add up to 20 items to cart
• Cart persists across sessions for logged-in users
• Checkout supports Stripe card + Apple Pay (no other methods in this milestone)
• Order confirmation email sent within 60 seconds of successful payment

If it's not in the list, it's not in the milestone. That's not hostile — it's the whole point of writing things down.

Pricing the Milestones

A common mistake: pricing each milestone as if it were an independent project. It isn't. Milestone 1 carries discovery risk. Milestone 5 carries integration risk. They shouldn't be priced flat.

Our rough shape for a 5-milestone build:

• M1 — Discovery & Spec (10 – 15% of total): Priced high on a per-day basis. This is where you earn the right to quote the rest.
• M2 — Foundation & Auth (15 – 20%): Predictable, well-scoped. Tighter margin acceptable.
• M3 — Core Feature Build (25 – 30%): The meat. Pad this one. This is where surprises live.
• M4 — Integrations & Edge Cases (20 – 25%): Third-party risk. Pad this one too.
• M5 — Hardening, QA, Launch (15 – 20%): Include a bug-fix budget explicitly. If you don't, launch week eats your margin.

We add a 20 – 30% risk buffer on M3 and M4, disclosed to nobody. If the project runs clean, that buffer becomes profit or gets returned as a discount on the next engagement — either way, it builds trust.

The War Story

A few years back we quoted a fixed-price marketplace build for a client who insisted the scope was "basically Airbnb but simpler". We had an assumption register, but we didn't have a re-baseline trigger. By milestone 3 we'd discovered the client wanted multi-currency, multi-language, and a bespoke dispute resolution workflow — none of which were in the SOW, all of which they considered obvious.

We delivered. We lost money. The relationship survived but was strained for a year.

The next contract we wrote had a re-baseline clause after milestone 2. On the very next project, we used it. The client didn't blink — they'd learned as much as we had, and the new number reflected the real scope. The project finished on time, on the revised budget, and they've been a client for four years.

The difference wasn't better estimation. It was giving both sides a way to update the deal without breaking it.

What About Payment Terms?

Milestone contracts only work if the money moves with the work. We invoice on milestone kickoff, not completion — meaning M2 is invoiced when M1 is accepted and M2 begins. This aligns cash flow with effort and prevents the "90 days late on final invoice" trap that kills small agencies.

For first-time clients, we ask for the M1 fee upfront before any work starts. Not because we don't trust them, but because a client who won't pay for discovery isn't going to pay for delivery either. It's a cheap filter.

Where We'd Start

If you're currently quoting fixed price and losing sleep, don't switch to T&M — most clients will resist and you'll lose deals. Instead, rewrite your next SOW with three additions: a numbered assumption register at the top, a re-baseline clause after your design or discovery milestone, and per-milestone acceptance criteria written as testable statements. Ship that version to your next three prospects. You'll close roughly the same rate, and the projects that do close will run measurably cleaner.

If you want a second pair of eyes on a contract shape before you send it, our team does this every week — have a look at how we structure engagements.