Why We Turned Down a Client Who Wanted a Fixed-Price, Fixed-Scope Contract

A few months ago, a prospective client asked us to quote a fixed price for a fixed scope of work, locked for the duration of the engagement — the traditional agency model, dollars and deliverables pinned down before anyone had written a line of code. We turned it down. Not because it wasn't good business — it would have been fine business — but because it's a worse deal for the client than it looks, and I'd rather lose the deal than let someone find that out three sprints in.

Why fixed-price, fixed-scope sounds appealing

It's not an unreasonable ask. Fixed price feels like certainty — you know the number, you know what you're getting, no surprises. For a lot of procurement processes, that predictability is the whole point of the exercise.

The problem isn't the desire for predictability. It's that fixed-scope contracts buy predictability in the number, at the cost of a specific and expensive kind of unpredictability in the outcome.

What actually happens inside a fixed-scope engagement

Scope gets written before anyone has built anything — which means it's written with the least information anyone will have at any point in the engagement. Requirements documents are a snapshot of what looked right in week zero. By week four, once real users or real constraints show up, some of what's in that document is wrong, and everyone involved usually already knows it.

Here's the part that matters: once the price is fixed to that original scope, the incentive on the vendor's side flips. Value stops being "build the thing that actually works" and starts being "build exactly what the document says, regardless of what's been learned since." Change requests get treated as scope negotiations instead of product improvements, because from the vendor's side, they are scope negotiations — every deviation from the original document is a threat to the fixed price, not an opportunity to build something better.

The client ends up locked into their week-zero understanding of the problem, paying full price for it, precisely at the moment they've learned enough to know that understanding was incomplete.

What we do instead

Every engagement runs in fixed sprints, each ending in a working demo. That cadence does the thing fixed-scope contracts can't: it keeps the plan honest against what's actually being learned, sprint over sprint, instead of locking everyone into a week-zero guess.

Capacity is elastic instead of contractually frozen — Sprint Mode when a push demands it, Cruise Mode for steady delivery, Pause between initiatives. Scope can genuinely change as the product reveals itself, because changing it isn't a renegotiation against a fixed number, it's just... the plan, updated with what the last sprint taught everyone. We wrote more about how this actually plays out operationally in our playbook on running elastic capacity.

What this costs us, and what it buys the client

I'll be honest about the tradeoff: fixed-price is an easier sale in a procurement process built around comparing vendor quotes line by line. Elastic, sprint-based engagements are a harder thing to put a single number on up front, and that costs us deals with buyers who need that single number to get budget approved.

What it buys the client is a product that reflects what was actually learned building it, not what someone guessed in a requirements document before a single sprint ran. Every one of our case studies — the B2B fintech that shipped an MVP in four sprints, the industrial AI startup that scaled a pod from one engineer to seven — happened because scope was allowed to track reality instead of a document written before anyone knew what reality looked like.

That's the actual trade a fixed-scope contract asks a client to make, whether or not it's stated out loud: certainty about the number, in exchange for building against information that's already stale by the time the ink dries. We'd rather not sell that trade, even when it costs us the deal.