Priced to Lose: Why "Add $20 a Month for AI" Is Not a Business Model

Posted on Nov 4 • Originally published at linkedin.com

Most teams spend a year perfecting an AI feature and ten minutes deciding what to charge for it. Then they are surprised when the economics do not work.

The usual move is to treat the AI capability like any other software feature: build it, add it to the product, and tack a round number onto the subscription. Twenty dollars a month, maybe thirty for the enterprise tier. It feels reasonable because that is how software has always been priced. The problem is that AI is not like the software you priced that way, and the pricing model you inherited quietly assumes a cost structure that no longer holds. The result is a feature that sells well and loses money on every heavy user, which is the worst outcome of all because success makes it worse.

Pricing is not the last step of shipping AI. It is part of the design, and the teams that treat it that way are the ones whose AI actually contributes to the business instead of silently draining it.

The pattern is easy to recognise once you have seen it. A company adds an AI feature, prices it as a flat monthly add-on, and watches adoption climb. Leadership is pleased. Then someone finally reconciles the inference bill against the revenue line and discovers that the most engaged customers, the ones using the feature dozens of times a day, are costing far more to serve than they pay.

Flat pricing on a variable cost is a bet that usage stays modest. With AI, the customers who love the feature use it relentlessly, and every use has a real marginal cost in tokens or compute. So the distribution of usage is not flat. A small group of power users drives most of the consumption, and under a flat price those users are being subsidised by everyone who barely touches the feature. The moment your marketing succeeds at driving engagement, your margin gets worse, not better.

This is the inversion that catches people. In classic software, more usage is pure upside because serving one more request costs effectively nothing. In AI, more usage is a cost event. A pricing model that does not account for that is not a pricing model. It is a hope.

The entire logic of software-as-a-service pricing rests on one assumption: near-zero marginal cost. Once the product is built, the cost of serving an additional user or an additional action rounds to nothing. That single fact is why SaaS can offer unlimited seats, unlimited storage tiers, and flat monthly fees without blinking. The expensive part was building it once.

AI violates that assumption directly. Every inference call consumes compute that someone pays for in real money, and the cost scales with how much the thing is used and how hard each use is. A long document, a complex reasoning chain, a high-resolution generation: these are not all the same cost, and none of them are free. The marginal cost of an AI feature is not zero and is not even constant. It is a live variable that moves with user behaviour.

When you price a variable-cost product with a fixed-cost playbook, you are no longer running a software business on that feature. You are running an unhedged position. You have fixed your revenue and left your cost of goods floating, and you will only find out how bad the position is after the customers who exploit it have arrived. The discipline AI pricing actually resembles is not software. It is any business that sells something with a real cost per unit, where margin is something you engineer rather than assume.

There are really only three primitives, and most good models combine them. Each one sends a different signal to the customer about what they are buying.

Seat-based pricing charges per user, regardless of how much each user does. It is simple, predictable, and familiar, and it works when usage per seat is roughly bounded and similar across people. Its weakness is exactly the heavy-user problem: it decouples price from cost, so it only survives if consumption does not vary wildly. For an AI feature with a long tail of intensive users, pure seat pricing is the trap described above.

Usage-based pricing charges for what is consumed: calls, tokens, documents, generations. It aligns price with cost almost perfectly, which protects margin, and it lets customers start small and grow. Its weakness is that it makes spend unpredictable for the buyer, and unpredictable spend is the single most common reason a procurement team says no. People will pay more for a bill they can forecast than a smaller bill they cannot.

Outcome-based pricing charges for the result, not the activity: per resolved ticket, per qualified lead, per completed document. It is the most defensible because it ties your revenue directly to the value you create, and it is the hardest to run because it requires you to define and measure the outcome rigorously and to carry the risk when the work is messy. When it fits, it is the strongest position available, because the customer is no longer comparing your price to a competitor's. They are comparing it to the cost of the outcome not happening.

Here is the number most teams never calculate before they launch: the cost to serve their heaviest ten percent of users. They model an average, multiply it out, and feel comfortable. But averages lie about AI usage, because the distribution is not normal. It has a fat tail, and the tail is where the money leaks.

If you have not segmented usage before pricing, you do not know your real margin. You know a blended figure that hides a cross-subsidy, and that cross-subsidy is fragile. It holds only as long as the light users outnumber and outpay the heavy ones. Change the customer mix, run a successful engagement campaign, or land a few intensive enterprise accounts, and the comfortable average quietly turns negative while your dashboards still show growth.

The teams that get this right instrument cost per user, not just cost in aggregate, and they look at the shape of the distribution before they set a price. They ask what happens to margin if the heavy tail doubles, because with AI it will. They build the price to be solvent at the tail, not merely at the mean. That is the difference between a feature that scales and a feature that becomes more expensive the more customers love it.

Costing the feature tells you the floor. It does not tell you the price. The most common mistake after the margin mistake is to set the price as a markup on inference cost, as though the customer cares what your tokens cost. They do not. They care what the work is worth to them.

The right anchor is the value of the thing you are replacing or creating. If an AI feature does in seconds what previously took a person an afternoon, its price lives in the neighbourhood of that afternoon, not in the neighbourhood of the compute bill. Cost-plus pricing on AI systematically leaves money on the table precisely where the feature is most valuable, because the compute cost is often lowest exactly when the value is highest. A model that saves a lawyer three hours costs you cents and is worth hundreds.

This is why the strongest AI monetisation is framed around outcomes and time saved rather than features and capabilities. "We do X for you" priced against the cost of X is a far stronger position than "we have an AI assistant" priced against the cost of running it. The compute cost sets the floor you must clear to be solvent. The value delivered sets the ceiling you are allowed to reach. Pricing is the discipline of living between them on purpose, not defaulting to the floor because it was the only number you bothered to calculate.

Separate from how you charge is how you package, and the two get confused constantly. The packaging question is whether the AI is a standalone add-on, a feature bundled into existing tiers, or the thing that defines a new premium tier. Each choice makes a different claim about what the AI is.

Bundling AI into the base product says it is table stakes, a reason to stay rather than a reason to pay more. That is sometimes exactly right, when the AI's job is retention and competitive parity rather than new revenue, and pretending otherwise by charging separately just slows adoption of something you needed everyone to use. Selling it as a premium add-on says it is a distinct, optional value worth a separate decision, which works when the buyer can clearly see who needs it and who does not. Making it a new top tier says the AI is the upgrade, the reason to move up the ladder, and anchors it against your highest-value customers.

The error is choosing packaging by habit instead of by intent. Charging separately for an AI feature whose real job was to defend the core product slows the adoption you needed. Burying a genuinely premium capability in the base tier gives away the one thing customers would have paid a premium for. Decide what the AI is for first, then let the packaging say the same thing the strategy says.

Put the pieces together and the shape is clear enough to act on.

A durable model starts from segmented usage, not a blended average, so you know your real cost to serve across the whole distribution and especially at the tail. It protects margin with a usage or outcome component so that heavy users pay in proportion to what they consume, rather than being subsidised into a loss. It anchors the price to the value of the work rather than the cost of the compute, so the business captures a fair share of what it actually creates. It packages the capability to match its strategic job, whether that job is new revenue, premium differentiation, or defending the core. And it gives the buyer enough predictability that procurement can say yes, because a model that is theoretically optimal and practically unbuyable earns nothing.

None of this is exotic. It is the ordinary discipline of selling something that has a real cost per unit, applied to a category that spent a decade pretending cost per unit did not exist. The teams still pricing AI like zero-marginal-cost software are the ones who will keep being surprised by their own margins, celebrating adoption while the unit economics quietly erode underneath it.

The feature was the easy part. Deciding what it is worth, to whom, and how to charge for it without going broke at scale is the part that determines whether the AI ever pays for itself. Price it like the variable-cost product it is, anchored to the value it delivers, or keep shipping features that win the demo and lose the invoice.

I write a field-note series on shipping AI that actually works in production. The original of this piece, and the rest, live on my LinkedIn. Originally published on LinkedIn.