AI Product Unit Economics: Cost, Margin and Control
An AI product has a variable cost per use that most SaaS doesn't. How I think about token/API cost per user, gross margin, caching, model routing, free-trial abuse and cost caps.
The thing nobody tells you when you bolt a model into a product: you just gave your SaaS a cost of goods sold. For years the whole appeal of software was that the second user cost basically nothing — build once, sell many, margin near 100%. AI products break that quietly. Every generation, every call, every long context is money out the door, per use, forever. So the question that classic SaaS could ignore — what does one user actually cost me? — becomes the question your business lives or dies on. Here's how I think about it, because I'd rather engineer the margin on purpose than discover it's gone at the invoice.
I'm going to use round, made-up numbers below purely to show the shape of the maths — they're illustrative, not real figures from anything I run. The point is the structure, which holds whatever your actual numbers are.
The one number: cost per user vs revenue per user
Strip everything else away and unit economics is one comparison: what a user pays you, versus what that user costs you in model calls, at the usage they actually reach.
That last clause is where people fool themselves. It's easy to model cost at average usage and price for that. But cost isn't driven by the average user — it's driven by the heavy one, and in most products a small share of users drive most of the usage. Price for the average and your best-engaged users can be your least profitable, or unprofitable outright.
So the real question is: at the 90th-percentile usage on a plan, does revenue still comfortably clear cost? If it only works for the median user, it doesn't work.
Where the cost actually comes from
AI cost isn't one number; it's a stack of drivers, and each is a lever you can pull:
| Cost driver | What inflates it | The lever |
|---|---|---|
| Calls per user | Chatty UX, retries, background jobs | Fewer, better calls; batch where possible |
| Tokens per call | Long prompts, big context, verbose output | Trim context; cap output; structured responses |
| Model choice | Sending everything to the most expensive model | Route to the cheapest model that's good enough |
| Repeated work | Recomputing the same thing | Cache results and embeddings |
| Failure & abuse | Loops, retries, scripted/free-tier abuse | Usage caps and a hard ceiling |
The mindset shift from normal SaaS: cost is now a product-design problem, not just an infrastructure line. Where you'd once tune a query, you now decide which model runs, on what input, how often, and with what ceiling. Those are design decisions, and they're where margin is won or lost.
The four levers, in the order I reach for them
1. Caching — stop paying twice
The cheapest call is the one you don't make. If two users (or the same user twice) ask for the same thing, or a step recomputes an identical result, you're paying for work you already did. Cache aggressively — results, embeddings, anything deterministic. It's the highest-return lever and the easiest to skip because it's invisible when it's working.
2. Model routing — cheapest-that's-good-enough
Not every task needs your most capable model. Classification, extraction, short transforms — plenty of work runs fine on a smaller, cheaper model, with the expensive one reserved for the tasks that genuinely need it. Sending everything to the top model is the most common way I see margin quietly evaporate. Route by task, not by habit.
3. Usage caps — bound the per-user cost
Every plan needs a limit, even a generous one. A cap isn't hostility to users; it's the thing that makes the plan's economics knowable. Without it, one enthusiastic (or automated) account can cost more than a dozen paying ones. Caps turn "cost per user" from a hope into a bounded number you can price against.
4. A hard ceiling — survive the failure cases
Separate from per-plan caps, you need a global "this should never happen" ceiling — the backstop for a runaway loop, a bug, or an abuse pattern you didn't foresee. It's the difference between a bad day and a bad invoice. I'd rather a feature fail closed than bill open.
In normal SaaS you optimize cost to improve margin. In an AI product you design cost to have a margin. It's not a tuning pass at the end — it's part of what the feature is.
Free tiers and abuse: "free" now has a COGS
This is where AI products diverge most sharply from the SaaS playbook. A free user of a database-backed app costs you rounding-error; a free user of an AI product costs you real money on every action. So the generous free tier that's great marketing for normal SaaS can be a slow leak for an AI one — and why I'm cautious about free plans is mostly this.
Abuse turns the leak into a tap: automated signups, disposable accounts, scripted heavy use. The defenses are the same levers, aimed at free: tight free limits, usage caps even on free, and the hard ceiling per account. Not stinginess — arithmetic. "Free" is a cost line now, and an unbounded cost line is a business you don't control.
Pricing follows the economics, not the other way around
Once you know the real cost-per-user curve, pricing has to respect it. The trap is pricing on competitor optics or a round number, then discovering the plan loses money at real usage. Two implications I keep front of mind:
- Flat pricing needs a cap, or your heaviest users are your worst accounts. Flat-with-a-limit is honest; flat-with-unlimited-AI is a dare.
- Feature-level profitability matters. Some features are cheap to serve, some are expensive; knowing which lets you shape plans and limits around the economics instead of against them.
What good looks like
- You know cost-per-user at high-percentile usage, not just the average — and revenue clears it there.
- Caching and model routing are designed in, not retrofitted after the first scary bill.
- Every plan has a cap; the account has a hard ceiling. Cost is bounded by design.
- Free is deliberately limited, because free has a variable cost now.
- Pricing respects the cost curve — flat plans are capped, and feature economics shape the plans.
The old SaaS reflex — build it, margin takes care of itself — is exactly the reflex that sinks an AI product. The good news is that unit economics here is designable: caching, routing, caps and ceilings are all within your control, and getting them right is as much a part of building the product as the feature itself. Treat cost as a first-class design concern from the start, and you get a product that makes money as it grows. Treat it as an afterthought, and you get one that costs more the more people love it.
Part of the Building AI Products guide. See also how I use AI without letting AI decide and subscription vs one-time pricing. The newsletter sends one finance-systems pattern, product decision or build lesson every two weeks.
Frequently asked questions
What are unit economics for an AI product?
Unit economics for an AI product are the revenue and cost attached to a single unit — usually a user or an account — with one twist that most SaaS doesn't have: a real variable cost per use, driven by model or API calls (tokens). In classic SaaS, serving one more user costs almost nothing, so gross margin is very high by default. In an AI product, every generation, every call, every long context costs money, so margin has to be engineered rather than assumed. The core question is simple and unforgiving: does the revenue from a user comfortably exceed what that user costs you in model calls, at the usage level they actually reach — not the level you hoped for?
How do you control AI model costs in a product?
With a handful of levers, used deliberately: cache results so you don't pay twice for the same work; route each task to the cheapest model that's good enough rather than sending everything to the most expensive one; cap usage per user or per plan so a single account can't run up an unbounded bill; and set a hard ceiling that stops runaway cost even in the failure cases (a loop, an abusive user, a bug). The mindset shift from normal SaaS is that cost is now a product design problem, not just an infrastructure line — where you'd once optimize a database query, you now decide which model runs, on what, how often, and with what ceiling.
Why is free-trial abuse a bigger risk for AI products?
Because a free user of a normal SaaS costs you almost nothing, but a free user of an AI product costs you real money on every action — so a generous free tier that's fine for a database-backed app can quietly bleed cash for an AI one. Abuse amplifies it: automated signups, disposable accounts and heavy scripted use turn a marketing cost into an open tap. That's why AI products lean toward tighter free limits, usage caps even on free, and a hard per-account ceiling — not because they're stingy, but because 'free' has a variable cost that has to be bounded or it becomes the whole P&L.