Spending more is not a strategy
There’s a story that made the rounds recently: a company proudly replaced six engineers with AI, then worked out it was burning more in tokens — the metered unit you pay for every time an AI reads or writes text — than those six salaries had cost. The automation came in more expensive than the people it replaced. The point of the story wasn’t “AI is bad.” It was that nobody had checked the number until the bill arrived.
If that sounds familiar, it should. We’ve now been sold the same idea three times.
The pattern: spend as proof you’re serious
Cloud did it first. For a good decade, a large AWS bill quietly read as a sign of success — you must be operating at real scale if you’re spending like that. Nobody framed it as a problem to solve. It was a line that only went up, and up looked like growth.
SaaS did it next. Seat counts, tool sprawl, “our stack” — the length of the list became a badge rather than a cost. Every team added its own tools, renewals auto-charged, and the total became something you paid rather than something you managed.
AI is doing it now, and loudest. There’s a real sentiment in the industry that if you’re not burning six figures a year per developer on tokens, you’re not serious about it. Somewhere right now an engineer is being told he’s a problem for using only a third of his token budget. Spend has been turned into a scoreboard.
Same script, three times: how much you spend gets treated as how good you are.
Why this keeps happening
It’s not because everyone’s foolish. It repeats for three durable reasons — and they’ll apply to whatever the next wave is, too.
- Spend is easy to measure. The bill is right there, one clean number. Value — did that spending actually produce anything? — is hard to measure and takes real work to pin down. So the easy number wins by default, and easy-to-measure becomes what-we-manage-by.
- The loudest advocates are on the receiving end. The people most emphatic that you should spend more are, more often than not, the ones selling the thing you’d be spending on. “Cloud is always cheaper” came from companies that sell cloud. “Burn more tokens” comes from the people selling tokens and the chips underneath them. That doesn’t make them wrong — it makes them not a neutral source.
- Budgets that reward spending get spent. The moment “used your full budget” is the safe answer and “spent a third of it” gets you questioned, people find ways to spend. You end up training your own team to protect the vendor’s revenue instead of your bottom line. Measure the wrong thing and you reliably get the wrong result.
Spend has been turned into a scoreboard.
The number that actually matters
The useful question was never how much did we spend? It’s what did each dollar of that spend produce?
That’s the boring number nobody posts about: cost per outcome. Cost per feature that actually shipped. Per support ticket actually resolved. Per dollar of revenue actually earned. If a tool — cloud, SaaS, or AI — is generating more value than it costs, spend away; that’s not waste, that’s leverage. The problem is never the size of the bill on its own. It’s a bill that nobody has tied to an outcome.
Spend is easy; ROI is hard. That difficulty is exactly why ROI is the one worth the effort — and why “we spend a lot on it” should make you ask a question, not feel reassured.
The bill that’s actually yours to fix
Here’s the part the headlines miss. The loud, dramatic version of this — six-figure token bills, replaced engineering teams — probably isn’t your situation. But the quiet version almost certainly is: a metered cloud bill nobody’s auditing and a SaaS list you stopped reading a year ago. Same disease, no drama, still expensive. There’s often real money hiding in there precisely because no single number ever forced anyone to look.
So the move isn’t to spend less out of virtue. It’s to break the spend-equals-serious reflex and act on the two things you can control:
- Get the steady, heavy workloads off the meter. The parts of your cloud bill that grow with usage — storage, data transfer, always-on servers — are the ones a per-unit meter punishes most, and the ones most exposed when the vendor reprices upward. Move those onto a flat-rate rented box (OVH, Hetzner, and similar — someone else owns and maintains the hardware; you pay one fixed monthly price for the term). A meter reprices and compounds; a flat rent doesn’t. This isn’t “flee to a server in a closet” — it’s stop standing on the line that keeps going up.
- Cap the parts that can run away. For AI and any usage-billed service, set a hard ceiling and per-user quotas. You can’t control the vendor’s per-unit price, but you can absolutely control your total — the default is unlimited liability, and that’s a setting, not a law of nature.
Both of those start from the same small shift: treating the bill as something you manage against an outcome, not a scoreboard you’re supposed to top.
If your cloud and SaaS bills have quietly become the thing you pay rather than the thing you manage, that’s exactly what I help with — I find the lines that grow the fastest and aren’t tied to any outcome, and show you which ones move to flat rate and which just get capped. Every message comes straight to me; I read and reply to each one myself, usually within a business day, and what readers send shapes what I write next. It’s just me for now, so that’s genuinely true. Send me your setup and I’ll show you where the money’s actually going — free, within a day.