Most AI products get priced the way SaaS always has: a monthly seat fee, tiered by feature count, sometimes a per-call add-on bolted onto the top. It is the pricing model everyone already understands, which is exactly why it is usually wrong for what an AI product actually costs to run and what it actually delivers.
The cost structure moved, the pricing model didn't
SaaS pricing assumes marginal cost per additional user rounds to zero. The tenth user costs about what the first one did, so a flat seat fee works because the business's economics are flat too. An AI product's marginal cost is not flat. Every response burns real inference cost, and that cost scales with usage in a way a fixed monthly fee was never built to track. Charge ten heavy users the same as ten light ones and the heavy users are subsidized by margin that isn't really there, discovered the first month the finance function actually reconciles inference spend against seat revenue.
This is not a rounding error a slightly higher price fixes. It is a structural mismatch between what the product does (variable, compute-bound work per request) and what the pricing model assumes: a fixed monthly right to use something. A team that prices this way is not being conservative. It is pricing an AI product like the software it resembles rather than the compute-bound service it actually is.
A seat fee prices access. An AI product's real cost is usage. Charging for the wrong one is how a profitable-looking product loses money at scale.
What the buyer is actually paying for changes too
The deeper problem is not cost, it's what the price communicates. A seat fee says: here is a tool, use it as much or as little as you want, we don't care. That is a reasonable message for software whose value is access to a capability the buyer already knows how to use. It is the wrong message for a product whose value is closer to outcome than access: a support agent that resolves tickets, a drafting tool that ships copy, a research agent that returns a finished brief. Buyers evaluating those products are not asking how many seats they need. They are asking what the product actually gets done, and what that is worth.
Usage-based and outcome-based pricing both answer that question more honestly than a seat fee does: usage ties price to the compute that actually got spent, outcome ties it to the result the buyer actually wanted. Neither is free to implement. Usage-based pricing needs real-time cost visibility most teams don't have on day one. Outcome-based pricing needs a definition of "outcome" precise enough to bill against, which is a genuine design problem, not a pricing footnote. It belongs in the same conversation as the product's ICP and positioning, not bolted on after launch. Naming the foundation area a venture is actually missing usually surfaces which of the three (strategy, brand, or the build itself) hasn't actually answered that question yet.
Free tiers make this worse before they make it better
A free tier is the fastest way to find out whether a pricing model actually survives contact with real usage, and also the fastest way to lose money if the model was wrong going in. A SaaS free tier costs almost nothing to run: a few unused seats on infrastructure that was going to exist anyway. An AI product's free tier costs real inference on every single request, which means an under-priced or unpriced free tier is not a growth loss-leader. It is a direct, compounding drain that gets worse exactly as the free tier succeeds at its actual job of attracting users. The teams that get this right treat the free tier itself as a pricing decision (a hard usage cap, not a feature cap) rather than a marketing decision made once and left alone.
The diagnosis, not the tactic
None of this is really an argument for usage-based pricing specifically, the same way a rebrand that only changes the vocabulary isn't really about vocabulary. It is an argument for pricing the thing the product actually is, against the cost it actually incurs, sold against the outcome the buyer actually wants, checked honestly rather than inherited from whatever the last SaaS product the founding team happened to work at. Most teams don't get this wrong because they haven't thought about pricing. They get it wrong because they thought about it once, early, before the product's real cost structure existed to check the thinking against, and never revisited it once it did.
