AI capex is someone else's problem, until it is your unit economics

The AI story in the financial press has become a story about capex. Data centers measured in gigawatts. GPU deals financed in circles between the companies buying and the companies selling. Spending large enough to show up in national economic statistics and to pressure the free cash flow of the biggest companies in the world. It is a genuinely important story, and for almost every company it is the wrong thing to worry about.

You are not going to solve the industry’s capex question. But its logic reaches you anyway, through a single number that decides whether your AI features are a business or a liability: the cost of running them.

The number that actually reaches your business

Every time your AI feature does its job, it costs something, in inference and in data. At the demo, that cost is invisible, because the feature runs a handful of times in front of a friendly audience. In production, the same operation runs thousands or millions of times, and the cost that was a rounding error becomes the whole economics of the feature.

This is the cost dimension of the Production Gap, and it is the one companies discover last, usually in a bill. A feature that costs more per use than it earns is not a product. It is a subsidy you are paying to your model provider, and the more successful the feature gets, the more it costs you.

Why cheap demos become expensive products

Three things turn a cheap demo into an expensive product, and all of them scale the wrong way.

Volume is the obvious one: cost is per use, so ten times the users is roughly ten times the cost, and the revenue does not always scale as cleanly. Complexity is the quiet one: the techniques that make AI features better, longer context, multiple model calls, agentic loops that reason over many steps, each multiply the cost per use, so quality improvements and cost increases arrive together. And provider pricing is the one outside your control: if your economics only work at today’s prices, you have a business that depends on someone else’s pricing decision.

None of these is a reason not to build. They are reasons to know your numbers before you do.

Model the cost before you build, not after

The fix is unglamorous and reliable: model the unit economics at the volume you actually expect, as a first-class part of the design, before the build. Estimate the cost per use, multiply it by realistic volume, and compare it honestly to what the feature earns or saves. Do it at ten and a hundred times your starting scale, because that is where the margin either holds or inverts.

If the number works, you build with confidence. If it inverts, you have not lost anything, you have found your roadmap: the architecture, model routing, caching, and pricing work that turns an unaffordable feature into an affordable one. Discovering that in a spreadsheet is cheap. Discovering it in a bill, after you have scaled, is expensive and sometimes fatal.

The strategic version

Zoom out and the discipline is the same one that separates a real AI strategy from a hopeful one. You are tying an AI initiative to a specific number in your business and checking it survives contact with reality. The macro capex debate is a loud reminder that AI has a real cost, and that cost does not disappear because a feature is impressive. It just moves down the stack until it lands on someone’s unit economics.

Make sure that someone is not you by surprise. Model the cost, design around it, and treat a feature that cannot afford its own success as a problem to solve before launch, not after. That is how you keep the industry’s capex story from quietly becoming your margin story.

If you want a clear-eyed read on whether your AI bets earn their cost at scale, that is part of what we do.