The Cash Flow Problem Nobody Mentions About Usage-Based Pricing

Let me start with what I agree with. The shift toward consumption pricing is genuine, it's driven by AI, and it's not optional for most of us.

End users are learning a new way to buy software. They've been trained by AI products to think in queries and tokens, and that expectation is bleeding into everything else they purchase. Two models are now in play that weren't mainstream a few years ago: usage or consumption billing, and outcome-based billing — worth the ten minutes it takes to read a straight technical comparison of the model options if you haven't settled on one yet.

"It took a whole, you know, 10 years for people to actually implement it. My guess is it'll be 10 months not 10 years that we have to implement this."

Ten months. Not because the technology is harder or easier, but because the market moves faster now and buyers have far more choice. If a competitor offers a consumption option and you don't, you don't get a decade to respond.

Here's my actual argument. The reason the perpetual-to-subscription shift took ten years was not technical. It was financial.

If you ran a perpetual-licence business, you expected large lumps of cash arriving throughout the year. Moving to subscription meant taking that same revenue and spreading it across many months. That's a fundamental change to how a business funds itself. Companies had to restructure how they operated to survive the gap — and many of them stalled, not because they didn't believe in subscriptions, but because they couldn't afford the transition.

We are now asking businesses to do something similar, but faster, and with a variable they've never had to model before.

"The ability to predict and plan your cash flows and revenue are critical to SaaS businesses."

That's the whole problem in one sentence. A subscription business knows roughly what next quarter looks like. Add a meaningful usage component and that certainty degrades — the trade-offs are worth weighing honestly rather than glossed over. Add a pure usage model and you may genuinely not know.

There's a lot of excitement about outcome-based billing — charging for a result rather than for consumption. I want to be blunt about this one.

"The hardest thing to implement is outcome-based charging essentially. There are a number of players in the marketplace experimenting with it but it is a quite a dangerous methodology to use."

Dangerous is the right word. With outcome-based billing, it becomes very unclear where your revenue is coming from, how much of it there will be, when it will arrive — or whether it will arrive at all. Some companies will make this work brilliantly. But there is a meaningful difference between a well-capitalised business running a deliberate experiment and a company betting its operating model on a billing method that nobody has yet run through a full downturn.

If you have a large cash balance, experiment. If you don't, understand precisely what you're taking on.

Three situations, three completely different levels of exposure.

A new AI startup has the easiest path. There's no installed base with expectations, no existing revenue model to protect, and — if they've raised capital — a cushion to absorb variability. They can design for consumption from day one.

A very large company with billions in ARR can absorb the volatility. The variable portion is small relative to the base.

Everyone in the middle — which is most of the industry — carries the real risk. An established subscription base, finite cash reserves, and now pressure to add significant revenue variability. This is the group being given advice written for the other two.

Hybrid pricing tends to get discussed as a packaging preference. I'd frame it differently: hybrid is what a sensible transition actually looks like when you take cash flow seriously.

"My prediction is the majority of folks, just like us, by the way, will end up with some kind of hybrid approach."

This is how we run our own business. We have editions with different price points, seat counts and feature sets, and an enterprise tier. Then we added AI to our products, which introduced a genuinely new variable tied to the volume of queries our customers run — the same consumption our own Zenmeter platform meters for customers doing exactly this.

So a customer pays us a predictable monthly amount, and on top of that we bill for consumption that changes month to month. I'll be honest about the complexity — internally I've described the result as "3D chess." But the base holds the forecast together while the variable layer captures the upside. You keep the predictability that lets you plan, and you still meet the buyer where they now are.

If you want to go deeper than a single quote can carry, I've written at length about why hybrid pricing makes sense as a standing SaaS strategy and, separately, about why AI specifically is what's pulling most software companies toward hybrid rather than a pure consumption model. Both get into more of the mechanics than I want to cover here.

Hybrid isn't a compromise. It's a hedge.

Let me make that concrete, because "hybrid protects your cash flow" is an empty claim until you see the numbers move.

Picture a customer paying you a flat $10,000 a month today — boring, forecastable, easy to plan around. You introduce a metered layer tied to their AI-feature usage, because that's where the real variability sits, and you split the contract: $6,000 stays fixed, covering the seats and the core product they'd use regardless. The remaining $4,000 becomes a metered charge on top, priced per query.

Run that forward a year. In a quiet quarter, the customer runs light and the variable component comes in at $2,500 instead of $4,000 — total revenue of $8,500, a 15% miss against the old flat fee. In a heavy quarter, usage spikes around a product launch and the variable component comes in at $6,000 — total revenue of $12,000, 20% ahead. Same customer, same contract, a $3,500 swing in monthly revenue depending on how they use the product that month.

That's not a flaw — it's the model doing what it's meant to do, tying revenue to value delivered instead of to a number picked a year ago. But if you build your annual plan on the old flat $10,000 and quietly assume the metered layer will land near the middle every month, the first quarter it doesn't will blindside you. Forecast the base and the variable layer separately. The base gives you a floor to run payroll against. Model the variable layer as a range — best case, worst case, and the case you'd actually bet on — and size your fixed costs to survive the worst case, not the average.

Do that across a portfolio of accounts rather than one, and the ranges start to net out at the aggregate level even while any single account stays unpredictable. That's the real argument for treating usage-based pricing as additive revenue rather than a threat to the base — a case worth reading in more detail here — but it only holds if you've modeled the downside first, not assumed it away.

Now the practical obstacle, and it's the one I see most often.

Most software companies cannot change their pricing quickly, because pricing lives inside their product code instead of being treated as configuration they can adjust on demand.

"Unfortunately, most SaaS companies hardcode their business model rather than using somebody like Nalpeiron to help them monetize."

This matters more than usual right now, because the correct strategy in a fast-moving market is to test. Try a consumption tier. See what it does to behaviour and to cash. Adjust. That approach only works if adjusting is cheap.

When pricing is hardcoded, every change becomes an engineering ticket, a QA cycle and a release. Months, realistically. And:

"Months could be the difference between winning and losing business."

That's the trap. The companies most exposed to cash-flow risk are usually the ones least able to iterate their way out of it — because every experiment costs an engineering cycle they can't spare. They end up making one large, irreversible pricing decision instead of a series of small, reversible ones. That is exactly the wrong way to manage financial risk.

If I were making this transition without our own platform underneath me:

Model the downside first. Not the optimistic case. Take your usage assumptions, cut them by a third, and check whether you can still make payroll.

Keep a predictable base. Preserve enough subscription revenue to cover fixed costs. Let the variable layer be upside, not survival.

Start with the AI or genuinely variable components. They suit metering naturally and are where buyers expect consumption pricing.

Decouple pricing from code before you need to. The value isn't one change — it's the ability to run twenty small experiments instead of one big bet, which is really a question of architecture, not willpower.

Instrument before you charge. You need usage data to price sensibly, and to defend the invoice when a customer questions it.

Treat outcome-based as a later phase. Get consumption right first.

There's a conversation happening in board rooms right now that doesn't get much airtime in pricing articles: what do you actually say when a board member asks why revenue guidance suddenly has a wider range than it did last year.

Don't hide the variability — name it, and show you've modeled it. Bring three numbers, not one: the base you're contractually guaranteed, a conservative case for the variable layer, and an upside case. A board that sees an $8.5M base plus a $1.5-3.5M variable range trusts the number more than a single $11M figure that turns out to be wrong in either direction.

Tie the variable layer to a leading indicator they already understand — usage volume, active seats running the AI features, whatever the metered unit is — so a miss on revenue has an explanation attached before anyone has to ask for one. And be explicit about the floor: what happens to the model if usage comes in at the bottom of the range for two consecutive quarters. If you can't answer that cleanly, you haven't finished the transition — you've just changed what the invoice measures.

The board doesn't need certainty. They need to see that the uncertainty is bounded, sized, and something you're actively managing rather than discovering after the quarter closes.

The shift to usage-based pricing is happening and it's happening fast. But the interesting question was never whether to adopt it — it's whether your business can absorb the volatility while you do.

The perpetual-to-subscription transition took ten years because of cash flow. This one is compressed into months, and the model is more variable. Being right about the direction won't help if the transition breaks your forecast.

Get the sequencing right, keep a predictable base, and make sure changing your mind is cheap.