Hourly versus fixed fee versus retainer

The standard argument against hourly billing is that it punishes efficiency — the faster you work, the less you earn, so the incentive points the wrong way. This is true, and it is also the least interesting thing you can say about pricing, because it treats the choice between hourly, fixed fee and retainer as a maturity ladder: hourly is what beginners do, fixed fee is what confident firms do, retainers are what you graduate to once a client trusts you. That ladder is wrong often enough to be actively bad advice. A firm that moves a difficult, scope-shifting client onto a fixed fee because fixed fee is what "grown-up" agencies quote is not maturing. It is volunteering to eat a risk it was previously pricing correctly.

The better way to think about the three models is as three different answers to one question: who carries the risk, and can that party actually do anything about it. Every consulting engagement has three risks running through it at once — estimation risk (will the work take longer than anyone guessed), scope risk (will the client ask for more than was agreed), and outcome risk (will the result actually land, regardless of hours or scope). Each pricing model assigns those three risks to a specific party by construction, not by accident, and the model works when the party holding a given risk is also the party with the power to control it. It fails, reliably and specifically, when that pairing is wrong.

Hourly: honest about estimation, silent about everything else

Hourly billing puts estimation risk entirely on the client. If the work takes forty hours instead of the twenty everyone guessed, the client pays for forty hours. This is why hourly gets a bad reputation among clients who have been burned by a vague scope and a bill that kept climbing — the risk sat with the party least equipped to control it, since the client usually cannot judge how long a task should take, that is precisely why they hired someone.

But hourly does something fixed fee cannot: it prices uncertainty honestly instead of asking one side to guess and quietly eat the difference. On work that is genuinely unpredictable — the first month of a new relationship, a debugging engagement, strategy work where the shape of the deliverable is not yet known — nobody can estimate accurately, and a fixed number produced under that condition is not a more confident price, it is a guess wearing a suit. Hourly at least admits what it does not know.

Where hourly earns its reputation is scope risk, which it handles well by construction: there is no separate scope negotiation, because every hour of scope is simply another hour on the invoice. That is also its weakness for the vendor. Hourly gives the vendor no protection against a client who is disorganized, slow to decide, or prone to changing direction mid-task — those clients cost the vendor real time in meetings, revisions and false starts, and hourly bills for that time honestly, but it does nothing to discourage the behavior, because the client bears the cost either way and some clients would rather pay more than decide faster.

Fixed fee: the number is the easy part

Fixed fee flips the estimation risk onto the vendor. Quote $18,000 for a project and it takes the vendor sixty hours or a hundred and twenty, the client pays $18,000 either way. This is the correct model precisely when the vendor is the party who can control the estimate — a well-scoped website redesign, a defined deliverable with a known shape, work the vendor has done twenty times before and can price from experience rather than hope. In that setting, fixed fee is a genuine service to the client: it converts an unknown into a known, and the vendor is compensated for absorbing that uncertainty because the vendor is the one actually equipped to manage it.

Fixed fee goes wrong, reliably, on scope. The number in the contract describes a scope, and the moment reality drifts from that scope — which it does on almost every project, because clients discover what they actually want partway through building it — someone has to decide whether the drift counts as "the same project" or "new work." If the client controls that judgment more than the vendor does, which is common, fixed fee has not eliminated scope risk. It has just moved the argument from the invoice to a conversation nobody wants to have, usually near the deadline, usually with both sides feeling taken advantage of.

The fix is not a better number. It is a named change-order process, agreed before the first deviation happens rather than invented during the first argument: any request outside the original scope document gets written down, priced separately, and approved before work starts on it — not folded in silently because refusing feels petty over what looks like ten minutes of extra work. The process matters more than the price attached to it, because a process that exists on paper but has never actually been invoked is not a process. It is a clause nobody has tested, and the first time it gets tested is usually the worst possible moment to find out whether it holds. Firms that run fixed fee well use the process on the very first small drift — a font swap that turns into a full page redesign — precisely so both sides know the mechanism works before a large one arrives. Firms that skip that step discover, on the large one, that the client has never seen a change order before and reads it as a betrayal of trust rather than as the system operating as designed.

Retainer: a subscription that prices access, not output

A retainer moves the arrangement again — this time the client pays for a fixed monthly amount of the vendor's time or attention, regardless of exactly what gets done with it. Outcome risk shifts toward the vendor in a softer, less contractual way than fixed fee, because a client paying a flat monthly fee starts expecting flat monthly value, whether or not that expectation was ever written into the agreement. Estimation risk mostly disappears as a live concern, because nobody is estimating a single deliverable anymore, they are pricing an ongoing capacity.

The retainer failure mode is specific enough to name, and it is not the same failure as the other two models. A retainer prices a queue, and a queue only produces value if someone keeps it full. In the early months this is usually the vendor's job by default — new relationships generate plenty of small requests — but nobody actually owns the queue long-term, because owning it was never assigned to anyone as a task, it was just assumed to happen. Then a slow quarter arrives on the client's side: a reorg, a budget freeze, a project that got deprioritized. The client's requests thin out, the vendor keeps billing the same flat number for less obviously visible work, and both sides notice but neither says anything, because naming it feels like accusing the other of bad faith. This runs for one quarter, sometimes two, and it ends in one of two ways: the client cancels abruptly, citing a general sense that they "weren't using it," or the relationship limps forward with quiet resentment on both sides — the client feeling overcharged for something invisible, the vendor feeling underappreciated for capacity that was, in fact, held and paid for as agreed. Both feelings are legitimate and both were preventable, and the prevention is almost always the same fix: a retainer needs a visible, mutually reviewed log of what the hours went toward, checked on a fixed cadence, not assumed to be self-evident from a monthly invoice that just says the same number every time.

Retainers suit ongoing relationships with a genuinely recurring need — a website that needs continuous small changes, an advisory relationship where the value is availability rather than deliverables, anything where the client benefits more from having someone on call than from any single output. They suit poorly a project with a defined end, where the flat number just obscures when the actual work finished and the billing kept going out of habit rather than need.

Blended models cost more to run than they look like they cost

The obvious response to all of the above is to combine models — fixed fee for the defined scope, hourly for anything outside it, maybe a small retainer layered on top for ongoing maintenance once the project ships. This is often the right call on the risk-allocation logic alone: it assigns each piece of work to the model that fits its actual risk profile instead of forcing one model to cover work it was never built for. But the blend has a cost that is easy to underprice, because it is administrative rather than financial. Every blended engagement needs its own bookkeeping to track which hours belong to the fixed-scope bucket and which belong to the hourly overflow, its own conversation with the client about which category a given request falls into, and its own moment, on every ambiguous request, where someone has to decide out loud which rules apply. A two-person shop running three blended contracts is running three small accounting systems, not three project plans, and that overhead is invisible on the pricing page and very visible on a Friday afternoon when nobody can remember whether last week's extra call was inside scope or outside it. Blend when the risk genuinely calls for it — a fixed core with hourly overflow is often the honest answer for a client whose scope is mostly known but not entirely — and skip it when the administrative cost of tracking two systems would exceed the value of getting the allocation slightly more precise.

Which model for which relationship

For a first engagement with a new client, hourly is usually the right default, not because it is more primitive but because neither side has enough information yet to price a fixed number honestly, and pretending otherwise just hides the guess inside the quote instead of admitting it. Once the relationship has run long enough that the vendor can estimate the client's typical requests with real confidence — after the first project, not before it — fixed fee becomes viable for defined, bounded work, provided the change-order process is written down and used from the first deviation rather than saved for the worst one. Retainers belong to relationships that have already proven themselves ongoing, where the value genuinely is availability rather than a deliverable, and where someone on both sides has explicitly taken ownership of keeping the queue visible rather than letting it go quiet until a slow quarter turns quiet into resentment.

None of the three models is a sign of how far along a firm is. They are three different bets about who can see a risk coming and do something about it, and the honest move is picking the bet that matches the actual client in front of you, not the one that sounds most like what a firm of your size is supposed to quote. The method for finding out which risks actually sit where in your own client list is the same one covered in our piece on pricing and positioning for small companies — look at the last twenty deals rather than the pricing philosophy on the homepage. And once the model is chosen, whether it survives contact with a client who has been paying the old number for two years is a separate, harder problem, covered in our piece on raising prices without losing the book. Whether the resulting number belongs on the website at all, rather than behind a conversation, is its own decision, and we've made the case for both sides in our piece on whether to put prices on your website.