You Billed for the Typing
For twenty years an hour was a decent stand-in for value, because the slow part of the work and the expensive part of the work were the same part. Generation went to zero on one of them and the invoice never noticed.
By Jason Waldrip 16:45 8 min read
You quoted three weeks. It’s Tuesday, the thing works, the tests are green, and you’re looking at an invoice with a blank line on it, doing arithmetic that has nothing to do with the work. Bill what you said and you’re charging for two weeks nobody worked. Bill what it took and you just cut your own price by two thirds, for delivering exactly what you promised, early.
Neither number is a lie. That’s the part worth sitting with. You can argue yourself into either one and be honest the whole way, which is usually a sign the argument is happening one level too low. The problem isn’t the number on the line. It’s the unit above it.
the approximation that used to be close enough
Nobody ever believed an hour was valuable in itself. We charged for hours because, for a long stretch, effort tracked outcome closely enough that the proxy held. The bulk of any project was production: typing, wiring, the fortieth form that had to exist before the interesting part could ship. The slow part and the expensive part were the same part. Charge for the slow part, and you were charging roughly for the thing that mattered.
That was never a principle, just a correlation, and it sat load-bearing under every hourly invoice, every story point, every headcount plan. Correlations are supposed to get audited when the thing underneath them moves. Nobody audited this one, because volume was the constraint for so long that it stopped looking like an assumption and started looking like the shape of the world.
two invoices at Brandfolder
The one I still tell. At Brandfolder, Ruby was crashing generating large zip files. Heavy IO in a runtime that was wrong for it, and the product going down in front of enterprise customers who had not signed up for that.
Two ways out. Throw hardware at it, which is an afternoon of work and a larger bill every month for as long as the product exists. Or carve the zip pipeline out into Go, real engineering with a start and a finish, which then delivers multi-gigabyte archives at minimal cost forever. We did the second one.
Here’s what I want you to notice. The hours in those two paths were not far apart. Provisioning bigger instances is not free labor, and the Go service was not a six-month project. The decision itself took an afternoon of thinking, and everything that made it worth anything happened before a line was written.
An hourly invoice cannot tell those two afternoons apart. It was never built to. It measures the one dimension along which they’re nearly identical.
the return that isn’t in the hour count
At CommercialTribe I replaced a weeks-long release cadence with automated testing and deploys that shipped in hours, across onsite engineers and a remote team in Argentina. That project had a start, an end, and a perfectly defensible hour count. You could audit it.
What it returned was not in the hour count. It was every release after it, for every engineer, for as long as the company ran. Weeks to hours is the difference between a team that learns and one that guesses, and that difference compounds daily against a fixed one-time cost. Bill it by the hour and you’ve priced a permanent change in the company’s metabolism at the going rate for a few weeks of one person’s attention. Both sides should find that suspicious. One of them usually doesn’t, and it isn’t the one paying.
a bet against your own leverage
So here’s the shift, and it was true before any of this got automated. It just wasn’t expensive enough to bother naming.
An hourly rate is a bet against your own leverage. Every tool you build, every convention that stops a class of bug from recurring, every hour of judgment that deletes a week of work, all of it arrives on your own invoice as a deduction. You are paid, precisely and mechanically, for the thing you have spent your entire career trying to eliminate.
That was survivable when the leverage was modest. A strong engineer was some multiple faster than an average one, the multiple was small enough to absorb into a rate, and everyone got on with it. Then generation went to zero. The fleet writes the code now, and what’s left in the room is choosing: which problem, which tradeoff, which card on the board actually matters. None of that consumes hours in any quantity worth billing. The most valuable thing I do in a week is frequently a twenty minute conversation where a team stops building something.
And the highest-value work of all leaves no evidence at all. The outage that didn’t happen generates no incident channel, no postmortem, no heroic Saturday. It produces a quiet quarter, and a quiet quarter has no line items.
start with the number, end with the design
The consulting world has been arguing this for years. Jonathan Stark wrote a whole book called Hourly Billing Is Nuts, and Patrick McKenzie put the engineering version in writing back in 2011: “Engineers are hired to create business value, not to program things.” He was right then. The invoice has been quietly disagreeing with him for fifteen years.
The most useful mechanic I know for it comes out of Basecamp’s Shape Up, a book about building software rather than pricing it, which lands on the same inversion anyway:
An appetite is completely different from an estimate. Estimates start with a design and end with a number. Appetites start with a number and end with a design.
Read that as a pricing sentence and it does the whole job. “How long will this take” starts from the work and derives a number. “How much is this worth” starts from the number and derives the work. The second question is the only one that survives contact with a fleet that can produce almost any design you ask it for.
This is how I actually operate at The Bushido Collective: flat retainers, measured on what ships and what gets prevented. Not because it’s clever positioning. Because I could not honestly send an hourly invoice for work whose entire value is that it made the hours unnecessary.
the part that’s genuinely hard
I’m not going to pretend the alternative is free, because the reason hourly has survived this long is that it solves a real problem.
Hours are legible. A client can count them, compare them, and argue about them, and that legibility is a real product an hourly invoice sells alongside the work. Value pricing asks a buyer to agree that something is worth a number before it exists, and then, in the prevention cases, to keep believing it when the proof is an absence. Nobody can audit the fire that never started. That burden lands entirely on you.
- Name the outcome before the work, in their language. Not “refactor the pipeline.” The release path goes from weeks to same-day, so a bad build costs an afternoon instead of a quarter. If you can’t state it that way up front, you don’t understand the engagement well enough to price it, and hours are hiding that from both of you.
- Price the recurring thing recurringly. A one-time fee for a permanent change in throughput is the same category error as an hourly rate, just wearing a nicer suit. Match the shape of the payment to the shape of the return.
- Write down what you decided not to build. Prevention has no artifact, so make one. The decisions you talked a team out of are the record of what you were worth, and they’re the first thing everyone forgets. This is the same reason to write down the why, aimed at your own invoice.
And hours are not always the wrong answer. When the scope is genuinely unknown, when it’s discovery and nobody can describe the finish line, when there’s no trust yet in either direction, an hourly arrangement is a fair truce while both sides learn what the work actually is. I’ve taken that deal. The failure isn’t using it. It’s letting the truce quietly become the model, and then wondering why getting better at your job keeps costing you money.
Go back to the invoice with the blank line on it. The number you’re stuck between isn’t the interesting question, and picking either one leaves the arrangement exactly where it was. The interesting question is why two competent parties agreed to transact in the one input that stopped being scarce, and kept doing it for years after everybody noticed.
What would you have to be able to name, out loud and in advance, to sell the other thing?
Jason Waldrip is a fractional CTO and CAIO through The Bushido Collective, working with founders drowning in AI-generated code and teams scaling past the leadership that got them here. Flat retainers, measured on what ships and what gets prevented. If you’re buying engineering by the hour and can’t say what you’re actually getting for it, that’s a conversation worth having. Work with me.
Written with AI assistance; the frame, the Brandfolder and CommercialTribe calls, and the judgments about what matters are mine. The Shape Up passage is quoted from Basecamp’s book and the McKenzie line from his 2011 essay, both linked above.