Fixed price vs hourly: which actually protects the client?

Most discussion of this treats it as a preference, like choosing an invoicing schedule. It is not. The billing model determines two things that matter a great deal: who carries the risk that the estimate was wrong, and what the vendor is structurally rewarded for.

What each model actually does

The incentive problem, stated fairly

Under hourly billing, the vendor's revenue rises with the hours consumed. That is simply what the model does. It does not follow that hourly vendors pad their timesheets — most are honest, and many are excellent. But they are honest despite the incentive rather than because of it, and the structure quietly discourages the things that would help you most: refactoring that makes the next feature faster, saying "that feature is not worth building," finishing early.

Fixed price inverts it. Once the number is agreed, every efficiency accrues to the vendor and every overrun is theirs to absorb. That alignment is the actual argument for it — not the budgeting convenience.

It also introduces its own failure mode, and it is only fair to name it: a vendor running over on a fixed quote is tempted to cut corners in the last stretch, where the invisible work lives — error handling, edge cases, tests. Which is exactly why the structural safeguards below are not optional decoration.

Why fixed price became more possible than it used to be

Fixed pricing has always been better for clients. It was often impractical because estimate variance was enormous: the honest spread between the good case and the bad case on a three-month build was wide enough that any fixed number had to carry a large risk premium — which the client paid for in the quote.

What narrowed the spread is that the work itself changed shape. A senior engineer working with AI agents produces in weeks what a small team produced in months, and — more importantly for estimating — the variance came down with the duration. Shorter projects are easier to price. Weekly working software means being wrong is discovered in week two rather than month three. That is why we can quote fixed numbers on mobile builds at all, and it is the practical consequence of how the work actually runs.

When hourly is the right answer

Insisting on fixed price for everything would be its own kind of dishonesty. Hourly is correct when:

• It is genuine research. If nobody knows whether the thing is possible, a fixed price is either a gamble or a padded number. Timebox the investigation, bill the time, then quote the build.
• You are buying capacity, not an outcome. Ongoing maintenance, a standing retainer, "be available when things break" — there is no deliverable to fix a price against.
• Discovery before a real quote. Sometimes the honest sequence is a short paid discovery phase that produces the scope the fixed quote is then written against. Ours is free at 30 minutes; bigger unknowns sometimes deserve more.

The tell for a bad hourly engagement is not the model — it is the absence of a ceiling. Any hourly arrangement should have a not-to-exceed figure and a checkpoint at which you can stop.

How to structure a fixed-price project so it protects you

Fixed price without these is just a number in an email:

• Written scope before work starts — the screen list, the integrations named, what is explicitly excluded.
• Milestone payments — a deposit, a mid-point, a balance at launch. Never the whole amount up front; never the whole amount at the end either, which shifts all risk onto the vendor and prices accordingly.
• A working demo every week, on a staging URL you can open yourself. This is what stops a fixed quote from becoming a black box.
• A named change process so additions get priced in the open rather than silently absorbed or flatly refused.
• Ownership on completion — code, repository and accounts in your name. A fixed price for something you do not end up owning is not a good deal at any number.