How to set billing rates when different people cost different amounts
A single blended rate systematically underprices your senior work and overprices your junior work. Here's the order the three rate questions need answering in, and why changing a rate is harder than setting one.
Most firms start with one rate. "We charge $150 an hour." It is clean, it is easy to quote, and it is right for about eighteen months.
Then it stops being right, usually in three ways at once. Your principal architect and your junior QA both bill at $150 — one is underpriced, the other is losing you bids. A client negotiated a discount last year and nobody wrote down where it applies. And a project comes in where the design work is genuinely worth more per hour than the testing, and your rate card has no way to say so.
At that point you need rates that vary by more than one thing. Most firms bolt this on badly, and then discover the expensive part: changing a rate is much harder than setting one.
A blended rate is not neutral — it has a bias
The usual defence of a single rate is that it averages out. It doesn't. It systematically transfers money away from senior-heavy work.
Take a 220-hour project, three people, and compare a $150 blended rate against role rates of $220 for architecture, $150 for development, and $85 for QA.
Testing-heavy shape — 40 architecture, 120 development, 60 QA:
- Blended: 220 × $150 = $33,000
- Role-based: $8,800 + $18,000 + $5,100 = $31,900
Architecture-heavy shape — 120 architecture, 60 development, 40 QA:
- Blended: 220 × $150 = $33,000
- Role-based: $26,400 + $9,000 + $3,400 = $38,800
Same hours, same blended price, and a $6,900 swing depending only on the shape of the work.
Testing-heavy
Architecture-heavy
Both projects are 220 hours. A blended rate cannot tell them apart.
Note what the first example shows, because it is the part most articles about rate cards leave out: role rates sometimes bill less. That is not a flaw. On testing-heavy work a blended rate is overpricing you, which is why those bids get lost to someone cheaper. Role rates are not a way to charge more — they are a way to be right, and being right means winning work you were previously pricing yourself out of.
Three questions, in this order
"What's our rate" is three questions wearing one coat. They need answering in order of specificity, most specific winning.
1. What is this kind of work worth? Design at $200, QA at $80, on the same project, for the same client. This is the rate that reflects the work rather than the worker, and it is the one most rate cards cannot express at all.
2. What is this person worth? Seniority, scarcity, the person a client asks for by name. This is the rate most firms already have, usually informally.
3. What did we agree with this client? The negotiated position — the discount for volume, the premium for a difficult engagement.
Most specific wins. If the task carries a rate, use it. If not, fall to the person's rate on that project. If not, the rate agreed with that client. If none of them, the project default.
Write that order down. Every argument about "which rate applies" is an argument about precedence that nobody settled in advance, and it always surfaces at invoice time, in front of a client.
A caution: you probably do not need all three. Each dimension you add is another thing to keep current and another way to be wrong. Add the one that is actually costing you money, not all of them because a system supports it.
The expensive part: rates change
You raise your development rate from $150 to $170 on 1 March. What happens to February's hours that haven't been invoiced yet?
There are two obvious answers and both are wrong.
Overwrite the rate. Now February's work reprices at $170 — you are billing a client a rate that was not in force when the work happened. If they notice, you are explaining why an agreed rate changed retroactively. If they don't, you got away with it. Neither is a business practice.
Never change rates. You undercharge indefinitely rather than face the problem.
The right answer is that a rate has a lifespan. It came into force on a date, and it may have stopped applying on another. An hour is priced by the rate that was in force on the day the work happened, not the day you got round to invoicing.
Practically: changing a rate should create a new version — close the old one with an end date, start a new one — rather than overwrite the old value. Your February hours find February's rate. March's find March's. Nobody has to remember anything.
And once it is invoiced, freeze it
One more rule, and it is the one that separates a system you can trust from a spreadsheet you have to check.
When an hour lands on an invoice, its price is fixed forever. Not looked up again. Not recalculated. Stored on the line item and never touched.
Without this, a rate change in June silently alters what your March invoice says it charged. Your records stop agreeing with what the client actually received, which is a problem the first time anyone reconciles — an accountant, an auditor, or a client querying an old bill.
If you take one thing from this piece: an invoice is a record of what happened, not a live calculation.
Where to start
- Write down your precedence order, even if you only use two levels today. The order is the thing that prevents arguments, not the rates.
- Check what happens to old hours when you change a rate. In most spreadsheets, the honest answer is "they silently reprice." Find out before it matters.
- Add one dimension, not three. Whichever of the three questions is currently costing you the most — usually role, if you have a wide seniority spread.
- Confirm your invoice history is frozen. Change a rate, then look at an old invoice. If the number moved, that is the first thing to fix.
None of this makes you more expensive. It makes the number defensible — which matters most in the conversation where a client asks why this hour cost what it did.
Disclosure: we build Timsio, which resolves rates in the order described here, versions them by date, and snapshots the price onto the invoice line so history cannot move. That's the bias to read this with. The precedence order and the effective-dating rule are worth adopting whatever you use — including a spreadsheet, as long as you know what yours does when a rate changes.