The Bill Is a Design Document

Your cloud invoice is the highest-fidelity map of your architecture you will ever get, it costs nothing, and it's already in your inbox. The problem is that nobody who can read it can change it, and nobody who can change it has ever seen it.

By Jason Waldrip, with Claude August 25, 2026 08:14

Finance forwards you the invoice with three words on top: this seems high. There’s a meeting Thursday called cost optimization, and by the time you sit down somebody has already built the deck. Rightsize the instances. Buy a year of reserved capacity. Shut the dev environments off at night. Get the rep on the phone and see what they can do. Every slide is a way to pay less for exactly the system you already have, and not one of them asks why the system does the thing it’s being billed for.

I’ve sat in that meeting from both sides. It’s a useful meeting. The savings are real, they close inside a quarter, and they are almost never where the money is.

nobody in that room can read it

The gap is in who touches the invoice, and it repeats in almost every company I walk into.

The invoice goes to finance. Finance can read money and cannot read the system. They get a few hundred line items with names like NatGateway-Bytes and Standard-Storage-Class-A-Requests, and no way to know that one of those lines exists because a service is chatting with a database across a boundary somebody drew in a hurry two years ago.

The engineers can read the system and never see the invoice. Ask a senior engineer what their largest cloud line item is and you’ll get a guess with a rising tone at the end. Ask what it was last month and you won’t get anything, because nobody sent it to them and nobody expected them to ask.

So the bill gets handled as a price, because the only people holding it can only see a price. And a price is a thing you negotiate.

what a discount can actually buy

37signals put real numbers on this in public, which almost nobody does. DHH wrote that HEY was paying over half a million dollars a year for database and search alone, and then he did the other half of the arithmetic in the same post: AWS was running close to a 30% margin, 18.5 billion in profit against 62.2 billion in revenue on his figures. He left.

That margin is roughly the ceiling on your negotiation. Everything above your vendor’s cost is in principle available to you, and in practice you’ll capture a slice of it once, in exchange for a multi-year commitment that makes the shape you currently have more expensive to change.

A discount is a one-time move against a recurring number. A design change moves the recurring number. Thursday’s meeting only knows how to do the first one, and it will keep being scheduled, quarterly, forever.

the bill is a design document

At some point in a rescue years ago I stopped reading the invoice as a bill and started reading it as a diagram, and I haven’t been able to unsee it since.

Every line item is a decision somebody made. Egress is data crossing a boundary you drew. Storage that only ever grows is a retention policy nobody wrote down. Compute that’s flat across a workload that is extremely not flat is a system sized for its peak because it couldn’t scale into one. A queue costing more than the work it queues is a queue that shouldn’t exist. None of this appears on the architecture diagram in the wiki.

Segment published the cleanest version of this I’ve read. They’d grown to over 140 services, one per destination, adding about three a month, and the sentence in their writeup that does all the work is that their operational overhead increased linearly with each destination added. Read that as an equation and not a complaint: cost was a function of destination count, by construction, and no amount of tuning any individual service touches a function. They collapsed the whole thing back into a single service and a monorepo. The numbers that moved didn’t move in a negotiation.

the calls I’ve made against it

The best cost discipline I’ve ever had was at Resipsa, a legal-practice SaaS I built and funded myself. I designed it to run at near zero, and the reason wasn’t rigor. The bill came out of my own account, every month, where I had to look at it. Founders who have felt that have a sharper instinct here than the ones who never have, and it isn’t close.

At CommercialTribe I moved us onto GCP and Kubernetes, and I want to be precise about the reasoning, because it inverts how that call usually gets made. Kubernetes was the cheapest path to stability at the load we actually had, which is a far narrower claim than “Kubernetes is cheaper.” Below that load it’s an expensive mistake and I’ll argue against it all day, which is most of what Earn It is about. All the judgment lives inside the phrase “at the load we actually had,” and you can’t evaluate that phrase without knowing what your current shape costs to run.

I’ve migrated to GCP more than once, for the same three reasons every time: cost, control, performance. Never for the first one alone. A migration is a different shape with a different bill, and if you move a bad shape you’ll get a bad bill in a new currency, a quarter of your team’s attention gone, and nothing learned.

The compressed version is the one I still tell: at Brandfolder, Ruby was crashing generating large zip files, the cheap answer sitting on the table was a bigger instance, and we built the pipeline in Go instead. Days of work against a line that would have grown every month we stayed.

the new line item

There’s a new SKU on the invoice this year, and it’s already collecting the same mistake.

You pointed everything at a frontier model because it was there and it worked on the first try. Classification, extraction, routing, tagging, a summarizer nobody reads. The bill lands, it’s a multiple of what anyone estimated, and the first instinct in the room is to ask about volume pricing. That’s the reserved-instance slide with a different logo on it. Most of that work never needed frontier reasoning, which is the entire argument for owning the model on the tasks boring enough to run yourself.

What’s genuinely new is the rate. A fleet spends against a design you approved once, and it spends at machine speed. An agent that re-reads the same file at every step, a retry loop with no ceiling, context rebuilt from scratch on every call: those are architectural decisions, they bill by the token, and nobody has to stay late to run the number up. The thing that used to rate-limit a lazy design was somebody having to sit there and do it. Volume is free now.

how I actually run this

1. Put the invoice in front of the engineers. Monthly, top twenty lines, translated out of SKU names and into the names your system actually uses. It costs one afternoon of somebody’s time to build that mapping, and it’s the highest-leverage afternoon in the whole exercise.
2. Ask what decision produced each line, not how to shrink it. “How do we get this down” gets you a smaller instance and a follow-up meeting. “What did we decide that makes this line exist at all” gets you the boundary in the wrong place.
3. Split the two questions and staff them separately. Price per unit is procurement, it’s real work, and somebody should be doing it. Units consumed is architecture, and it’s yours. Blending them is how a cost program runs for a year and moves nothing.
4. Decide out loud what you’re willing to pay for. Some expensive lines are correct. Multi-region under an uptime commitment is correct. Reading the bill isn’t an exercise in making it smaller, it’s how you confirm every large number on it is one you’d choose again today.

Thursday’s meeting still happens, and I still take the reserved instances, because free money is free money and I’m not precious about it.

What I want before that meeting breaks up is one person who can put the top line on the screen, name the decision it came from, say roughly who made it and when, and then say whether we’d make it the same way now. Most companies don’t have that person anywhere on the org chart. A lot of them have a very good deck.

So: your biggest line item this month. What’s it a picture of?