Classic SaaS has a beautiful property: the marginal cost of one more user is close to zero, which is how the industry settled on 80–90% gross margins and simple per-seat pricing. AI features break that property. Every generation, every chat turn, every summarisation has a real marginal cost that scales with usage, and AI-heavy products commonly run at 50–60% gross margin instead. Founders who bolt AI onto a flat-fee plan without redoing the unit economics are making a bet — usually without realising it — that their heaviest users will stay light. They will not.
The margin math founders skip
Work one concrete example. Say your plan is €29/month and the AI feature costs you an average of €0.04 per use in inference. At 100 uses a month, COGS is €4 — a comfortable 86% margin on that user. The problem is that AI usage is never normally distributed: it is a power law. The median user does 40 uses; the 95th-percentile user does 2,000. That power user costs you €80 a month against €29 of revenue — you are paying them €51 for the privilege. A handful of such users can erase the margin of an entire cohort, and they are precisely the engaged users you least want to throttle.
This is why the margin question and the metering question are inseparable. Whatever pricing model you pick, you need per-user consumption data first — which is an application-side build, the metering-and-quota layer I covered in my Laravel work on per-user token budgets. Meter first, price second.
The four models, honestly compared
| Model | Revenue predictability | Margin protection | Buyer friction | Metering complexity |
|---|---|---|---|---|
| Flat fee (AI included) | Excellent | Poor — power users are unbounded losses | None — easiest to sell | Low (but build it anyway) |
| Credits | Good | Good — consumption is capped by purchase | Moderate — customers must understand a credit | Medium |
| Hybrid (base + included allowance + overage) | Good | Good — tail is priced, core is predictable | Low–moderate | Medium–high |
| Pure usage | Poor — spend anxiety suppresses adoption | Excellent | High — procurement hates open-ended bills | High |
Two failure modes account for most bad outcomes. Flat fee fails silently: nothing breaks, the product grows, and the margin quietly erodes as engagement improves — success literally costs you money. Pure usage fails loudly: users hesitate to click the AI button because every click has a price, so adoption never materialises. The industry's convergence toward the middle two models is not fashion, it is survivorship.
What the market actually settled on
- Airtable prices AI as credits included per seat per plan, with higher tiers carrying bigger allowances — a hybrid dressed as per-seat pricing, which keeps the buying motion familiar.
- GitHub Copilot moved from a purely flat subscription to plans with a monthly allowance of premium requests plus pay-per-request overage — the canonical example of a flat-fee product retrofitting usage pricing once the power-user math became undeniable.
- Intercom's Fin charges per resolution — outcome-based pricing, the boldest variant of usage pricing, which works because "a resolved ticket" is a unit buyers value directly.
The pattern across all three: the unit sold to the customer is a product unit (a request, a resolution, a credit), never a token. Tokens are your cost accounting; exposing them to customers exports your engineering complexity into their procurement process.
The decision matrix I use with founders
- Is AI incidental to the product (autocomplete, small assists)? Flat fee. Absorb it as COGS, cap abuse quietly, keep the pricing page clean.
- Is AI a core feature with visible per-use value? Hybrid. Each plan includes a monthly allowance sized so ~90% of users never hit it; the top decile pays overage or upgrades. This protects margin exactly where it leaks.
- Do usage patterns vary wildly across customers (agencies, API customers)? Credits, purchasable in packs. Pre-purchase smooths your revenue and gives customers a budgeting handle.
- Can you price the outcome rather than the activity? Usage/outcome pricing — but only if the outcome unit is indisputable. Per-resolution works; per-token never does.
Metering realities before you commit
Whichever row of the matrix you land on, the implementation floor is the same: an idempotent usage-event ledger (every AI action recorded once, with tenant, feature and cost), allowance counters that reset on billing cycles, and proration answers for mid-cycle upgrades. Credits add expiry policy and refund handling on failures — decide before launch whether a failed generation consumes a credit, because customers will ask in week one. None of this is exotic engineering, but it is real scope: budget it alongside the AI feature itself, not as an afterthought. If margins stay tight after pricing is fixed, the cost side has its own levers — caching, routing, batching — which I have written about separately.
Price the product unit, meter the token. Hybrid pricing — a flat plan with an included allowance and priced overage — protects margin exactly where flat fees leak, without the adoption-killing anxiety of pure usage billing.
My default recommendation, when there is no strong reason otherwise: hybrid, with allowances set from real metering data rather than guesswork, reviewed one quarter after launch. It is the model your customers already understand from their phone plan — and the one that lets your best users stay your best users instead of your biggest losses.
One last note for products already live on a flat fee: reprice forward, not backward. Grandfather the existing base at their current terms, introduce the allowance on new plans, and give heavy legacy users a generous migration window with their own usage data in front of them. Copilot's transition showed the shape of it — the customers who cost the most are also the ones who value the feature most, and shown honest numbers, most of them upgrade rather than churn.
Launching an AI feature and unsure how to price it — or watching one eat your margin already? I help SaaS teams with both the metering build and the numbers — let's talk.