Where AI Actually Becomes a Revenue Line

Start by admitting it is a cost

Adding AI to a product you already ship does not create revenue. It creates inference bills, latency, an evaluation burden, and a new category of support ticket where the software was confidently wrong.

That is not an argument against it. It is the honest starting position, and I think skipping it is why so many teams shipped an AI feature and cannot tell you what it earned.

So the question is not whether to use AI. It is which of these you are doing, deliberately:

Making something you already sell more valuable, so you can charge more or churn less. Making something cheaper to deliver, so margin improves or a lower price point opens. Or selling something new that was not previously deliverable at any sensible price.

Those have different economics and different proof. Mixing them is how a feature gets shipped with no way to evaluate it, because nobody agreed which one it was meant to be.

My bias, for what it is worth: the third is where the real money is, and almost everyone attempts the first because it is the least disruptive to the roadmap.

The four places it works

Charge for an outcome that was previously uneconomic. Work that required a person and therefore had a price floor set by salaries can now sometimes be delivered at a fraction of that. If your product can now produce a deliverable that customers were paying a firm to produce, you are not selling a feature, you are selling the outcome, and it prices against what they paid before rather than against your other tiers. This is the strongest position available and it is the hardest to build.

Remove a step between signup and value. Most products lose people at a specific point: an empty state, a configuration screen, an import that requires clean data. If a model can do that step, more people reach the moment they would have paid at. This shows up as conversion rather than as a line item, which makes it easy to underinvest in and easy to measure properly if you bother.

Cut delivery cost until a new tier is viable. If support, onboarding, or manual review is what makes small customers unprofitable, reducing that cost makes a lower tier possible. That opens a segment you previously had to turn away.

Package the capability as a scoped service. Building the workflow for someone else, under a defined scope and a fixed price. This is a real business and I want to be clear it is a different one: revenue scales with delivery capacity rather than with users. That is not worse. It is faster to start, harder to compound, and it is how most people should test whether the demand exists before building a product around it.

The number that decides all of it

Cost per unit of value delivered. Not cost per token, not cost per month. The cost of producing one of whatever it is the customer is paying for.

Most teams have never calculated it, which is how you get a flat monthly price on a feature whose cost scales with usage. That structure is fine while adoption is low and becomes a margin problem exactly when the feature succeeds, delivered by your most engaged customers. I have watched this specific mistake more than any other.

The work is unglamorous. Instrument the actual cost of a completed unit, including retries, failures, and the calls users make that produce nothing. Then compare it to the price you charge for that unit, and to the price of the alternative your customer is comparing you to, which is often a person rather than another tool.

That comparison tells you the pricing model, not your preference. If cost scales with usage, price should scale with something, ideally the outcome rather than raw consumption, because customers hate paying for tokens and are comfortable paying for results. If cost is genuinely fixed per account, a flat tier is honest.

And because margin here is a direct function of how much compute a unit consumes, the engineering work that reduces context size, caches aggressively, and avoids sending the same material repeatedly is not an optimization task. It is pricing work wearing different clothes, and it belongs in the same conversation as the pricing page.