Fixed-price web projects punish the client who learns
The claim A fixed-price software contract does not remove your risk. It sells you the risk back at a markup and then charges you again, through change orders, every time you learn...
The claim
A fixed-price software contract does not remove your risk. It sells you the risk back at a markup and then charges you again, through change orders, every time you learn something during the project. For anything beyond a well-specified rebuild, a capped time-and-materials arrangement with a fixed-price discovery phase costs less and produces a better result.
Where the markup comes from
A vendor quoting a fixed price is making a bet with your money. If the estimate is 400 hours at $150 CAD per hour, the honest quote is not $60,000. It is $60,000 plus a contingency sized to the uncertainty, because the vendor absorbs every overrun. Typical risk premiums in this market run 20% to 40%.
| Line | Amount (CAD) |
|---|---|
| Estimated effort, 400 h at $150 | $60,000 |
| Risk premium at 30% | $18,000 |
| Fixed-price quote | $78,000 |
| Actual effort, 400 h | — |
| You paid for hours never worked | $18,000 |
When the project goes smoothly, you funded a contingency nobody spent. When it goes badly, the vendor's margin is under pressure from week three, and every conversation about scope becomes adversarial. Neither outcome is what you were buying.
The change-order trap
The deeper problem is behavioural. A fixed price requires a fixed specification, and a fixed specification requires you to know, before any work begins, exactly what you want. In practice you discover on week five that the payment provider needs a webhook you had not accounted for, or that a workflow which made sense on a whiteboard is unusable on a phone.
Under a fixed price, that discovery is a change order. It gets scoped, quoted, and approved, which is usually two weeks and often priced at a higher rate than the base contract because it sits outside the competitive quote. The rational response, for both parties, is to stop discovering things. That is why fixed-price projects so often ship exactly what was specified and exactly what nobody wanted.
The structure we recommend instead
- Fixed-price discovery. Two to three weeks, priced firmly, typically $8,000 to $15,000 CAD. It produces a technical design, a prioritised backlog with estimates, a risk list, and a working prototype of the riskiest piece. It is a real deliverable you own, and you can take it to another vendor.
- Capped time and materials for the build. Billed on actual hours, with a not-to-exceed ceiling drawn from the discovery estimate plus 15%. You pay for work performed; the vendor cannot invoice past the cap without your written agreement.
- Two-week increments with a working deployment at the end of each. Not a status report. A URL.
- A written exit at any increment boundary. Thirty days' notice, source code and infrastructure access handed over, no penalty.
That fourth clause is the one that matters most and the one clients most often forget to ask for. It converts a twelve-month commitment into a series of two-week decisions, which is the actual protection you were seeking when you asked for a fixed price.
The objection, answered
The reasonable objection is that a cap is not a price, and a board or an owner needs a number to approve. That is fair, and the answer is that the cap is the number you approve — it is simply a ceiling you may not reach rather than a floor you certainly will. In practice, capped engagements we have run land between 80% and 100% of the ceiling, which means the client's realistic outcome is somewhere between the fixed-price quote and 20% below it, with the option to stop early if priorities change.
The second objection is administrative overhead. Tracking hours does cost something. Budget an hour a week for the vendor to produce a burn report showing hours spent, hours remaining against the cap, and what shipped. If a vendor cannot produce that in an hour, the tracking is not your real problem.
When fixed price is right
It is genuinely the correct instrument in three cases: a rebuild of an existing system whose behaviour is already documented and observable; a well-bounded integration with a stable, documented third-party API; and any engagement under roughly $15,000 CAD, where the overhead of tracking hours exceeds the value of the precision.
What to ask for on Monday
If you are mid-procurement right now, ask every bidder three questions and compare the answers rather than the totals:
- What contingency percentage is in this number, and what happens to it if the work goes smoothly?
- What is your hourly rate for change orders, and how does it compare to the effective rate in this quote?
- What do I own, and how quickly can I leave, if we stop after eight weeks?
A vendor who answers all three plainly is one you can work with under any contract structure. A vendor who cannot answer the first one has either not estimated the work or is not going to tell you what they found.
