Newsletter AI Learning, Keeping It Human Call 647-641-0643
Christopher Ross

Delivery engagements are fixed price.

You see one number before we start. Scope protections live in the contract, not in surprise invoices.

Hourly T&M hands the buyer all the risk and hands me a metre. I’d rather take the risk myself, quote what I think the work is worth, and protect both of us with named scope.

What I do

Two side-by-side risk-allocation diagrams. In the left panel, labelled Fixed price, an identical labelled weight reading Scope variance: legacy quirks, drift, unknowns sits on the seller pan (gold), with the buyer pan (navy) empty and raised. In the right panel, labelled Time and materials, the same weight sits instead on the buyer pan (navy), with the seller pan (gold) empty and raised. The same unknown lands on a different side depending on how the engagement is priced.
Same scope unknown lands on different shoulders depending on how the engagement is priced. Both models are legitimate in their right contexts; the diagram shows who carries the risk, not which model is better.
  • Quote a single number that covers the work as scoped.
  • Document scope in writing: what’s in, what’s out, what’s deferred.
  • Name how change orders work before we begin. New requests get quoted as fixed-price addenda, not added quietly to a running bill.
  • Build a 15% complexity buffer for the unknowns I can predict (legacy plugin surprises, broken DNS, missing access). Charge nothing for the unknowns I caused.
  • Phase-gate large engagements at 33%, 66%, and 100% of scope so you can decide whether to proceed at each milestone, not just at the end.

What I decline

  • Open-ended hourly engagements where you carry the metre risk and I carry none.
  • Retainers as the default delivery vehicle. Retainers are for ongoing partnerships after the build, not for the build itself.
  • Engagements where “we’ll figure out scope as we go” is the plan. That’s a fee structure, not a project.
  • Verbal scope changes that don’t get documented before the work starts.

Why this is the position

People deserve to know what they’re buying.

A fixed price forces me to think clearly about the work before I quote it. Vague quotes produce vague work. If I can’t price it, I can’t deliver it well. If I can price it, you should know the price.

Scope creep is a real risk. The fix isn’t a metre that runs while we figure things out. The fix is a clear scope, a named change-order process, and the senior judgement to know when something’s drifted before the bill does.

What happens if the scope changes mid-project

Scope changes on almost every project. The question isn’t whether it happens, it’s what happens next, and that’s written into the contract before we start, not improvised when it comes up.

When something outside the original scope shows up, whether it’s a page nobody mentioned, a feature that turns out to need a plugin, or a redesign mid-build, I write a short change order: what’s new, what it costs, and how it affects the timeline. You approve it before the work starts. There’s no metre running while we figure it out, and no surprise line item on the final invoice.

If the change is small enough to absorb without affecting the price or the deadline, I’ll usually just tell you it’s covered and move on. The change-order process exists for the changes that actually cost something, not for every small adjustment along the way.

See also