A founder I know showed me his product roadmap last year with genuine pride. Eleven AI features, all shipped in two quarters, all announced on LinkedIn. Then he showed me the P&L. His cloud and model costs had gone from roughly 4% of revenue to somewhere north of 19%, and his pricing page had not changed a single euro. When I asked which of the eleven features customers had asked to pay for, he went quiet for a moment and said none of them, but the features were the reason people were still renewing.

That is not a reason. That is a hope dressed as a reason, and it is now the single most common way I see otherwise disciplined software businesses walk their gross margin down five to fifteen points without a board conversation about it.

The pattern is easy to describe and hard to see from inside. You ship AI because everyone is shipping AI. You do not charge for it because charging for it feels risky in a competitive renewal. The cost of running it is variable and monthly, and it scales with usage rather than with revenue. Six months later you discover that your most engaged customers, the ones your customer success team celebrates in the weekly meeting, are the ones destroying your unit economics. I have watched large corporate innovation teams and small startups make exactly this mistake in different currencies, and the mechanics are identical.

“AI-powered” stopped being a reason to buy roughly eighteen months ago

Here is the contrarian part, and I say it as someone who has been building with machine learning since well before it was a marketing category. When I was working on lending models and hyper-personalization at HSBC in Hong Kong, the machine learning itself was a genuine moat. Very few institutions had the data infrastructure, the modelling talent, and the regulatory patience to do it at all. If you had it, you could point at it and win business, because the alternative was a human underwriter with a spreadsheet.

That world is gone. The capability that took a bank a two-year programme and a team of specialists is now a paid API and a weekend. I do not say that to be dismissive of good engineering, because the gap between a demo and a production system that does not embarrass you at scale is still very real. But the customer does not perceive that gap. The customer has a ChatGPT subscription, has watched a colleague build something passable in an afternoon, and has been told by three of your competitors that they too are AI-powered.

Which brings me to the sentence I now repeat in every product review I sit in: if “AI-powered” is no longer a reason to buy, it cannot be a reason to charge more. Those two things move together. You are allowed to charge for an outcome that AI makes possible. You are not allowed to charge for the presence of AI, because the presence of AI is table stakes and the market priced it at zero some time ago.

The uncomfortable corollary is that AI features are, by default, a pure cost centre with a marketing benefit that decays fast. The marketing benefit decayed the moment your competitor shipped the same thing. The cost did not decay. The cost recurs, every month, indexed to how much your customers like the feature.

The obvious fix fails because usage and value are not the same shape

The instinct, once a founder sees the bill, is to bolt on usage-based pricing. Credits, tokens, “AI actions”, some meter that turns consumption into revenue. This is directionally correct and usually implemented badly, because the meter gets attached to the thing that is easy to count rather than the thing the customer believes they are buying.

Counting tokens is easy. No customer has ever had a budget line for tokens. When you meter something the customer does not recognise as valuable, three things happen in sequence. First, they cannot forecast their spend, which makes procurement nervous and slows deals. Second, they optimise against the meter, which means they use the feature less, which means the feature stops generating the engagement you built it for. Third, and this is the one that hurts, they start comparing your per-token price to the raw API price they can look up in thirty seconds, and you have handed them a spreadsheet with which to negotiate you down.

I saw a version of this dynamic in consumer hardware, building products in China with the Jean-Michel Jarre venture. We went from one product to eight, and the temptation every single time was to add a feature because it demoed well. What we learned, expensively, is that a feature which adds bill of materials cost but does not change the reason someone picks your box off the shelf is not a feature. It is a tax you have decided to pay on every unit you sell, forever. Software founders think they are immune to this because software has no bill of materials. Inference gave software a bill of materials. Most people have not updated their mental model.

The other failure of the obvious fix is timing. Pricing gets discussed after the feature ships, in a panic, when the cost has already become visible. By then the feature is in the product, customers have it, and taking it away or putting it behind a paywall is a retention conversation you did not budget for. The pricing decision has to happen before the spec, not after the invoice.

The three questions I ask before approving anything with a model behind it

Running a climate-tech company, I am unusually sensitive to the difference between a cost you can defend and a cost you are simply absorbing. In climate, everything is measured against a baseline and a counterfactual, because that is how the market decides whether what you did was real. I have started applying the same discipline to AI features, and it comes down to three questions that must be answered in writing before anyone opens a spec document.

Name the line item it replaces. Not “saves time”. Not “improves productivity”. A line item that exists somewhere in the customer’s budget today. A contractor invoice, a headcount, a licence for another tool, an error rate that costs money in rework or penalties. If the AI feature reduces the time a compliance analyst spends on document review from six hours to one, then the line item is analyst hours and you can put a number on it, because that person has a fully loaded cost and your customer knows what it is. If you cannot name the line item, you are building a feature that improves the experience, which is fine, but it must then be funded out of your existing price and capped in cost accordingly.

Name the unit you will meter. The unit should be the thing the customer counts anyway: documents processed, claims reviewed, sites monitored, invoices reconciled, reports produced. If they already count it, they can forecast it, and the meter feels like fair trade rather than surveillance. Choosing this unit also forces the engineering conversation early, because now you need to know your inference cost per document, not per month, and you need to know what happens to that cost when a customer sends you a 400-page PDF instead of a 4-page one. Most teams discover at this point that their cost per unit varies by a factor of twenty across their customer base, and that the variance, not the average, is what will kill them.

Name the price you will defend when the customer says their own GPT can do this. They will say it. Someone in the room will always say it. Your answer cannot be that your model is better, because you do not know that and they will not believe it. Your answer has to be about everything around the model: the data you have access to that they do not, the integration into their workflow, the audit trail, the fact that when it gets something wrong there is a company on the hook rather than a chat window. If you cannot articulate that answer in two sentences to a sceptical CFO, the feature is not defensible and the price will collapse to the cost of the API.

What to do on Monday

Start with the data you almost certainly have and have not looked at. Pull your AI-attributable infrastructure cost by customer for the last three months, and put it next to what each of those customers pays you. In most portfolios I have looked at, somewhere between five and fifteen percent of accounts are consuming a wildly disproportionate share of inference, and the correlation between that consumption and their contract value is close to zero. Some of them are probably running you at negative gross margin. You need to know which ones by name before you decide anything else.

Then stop approving AI features without the three answers. Not as a bureaucratic gate, but because the act of answering them is what turns a positioning move into a product decision. Features that pass will generally be narrower than what your team wanted to build, aimed at a workflow you can price rather than a capability you can announce, and considerably less exciting on a launch post. They will also be the only ones that still make sense in eighteen months, when the novelty premium is fully gone and all that is left is arithmetic.

The companies that will be fine are not the ones with the most AI. They are the ones who decided, before writing a line of code, exactly which cost they were removing from someone else’s P&L and exactly how they would be paid for removing it.

I write from twenty years of building businesses between Europe and Asia. If your company is facing this, start a conversation.