AI SaaS unit economics is the gross margin left on a single customer after every variable cost of serving them: model inference, retries, embeddings, vector storage, human review, and support. Unlike classic software, that cost climbs with usage. A flat monthly price can therefore produce a customer who costs more to serve than they pay.
I've watched founders demo something genuinely good, then answer "what does one customer cost you?" with last month's API bill divided by their signup count. That average is the most dangerous figure in the business. It hides the account that ran 4,000 generations on a $49 plan, and that account is usually your loudest advocate.
Scope note. This is about pricing a product you sell, not what your team spends on Copilot and Cursor seats internally. That's a separate budget with separate traps, covered in what AI coding tools actually cost past the trial. One is an R&D line item. The other decides whether your revenue is real.
gross margin an AI SaaS should target at steady state
variable cost lines per customer, of which most teams count two
the account whose gross margin actually tells you if pricing survives
Why does AI break the classic SaaS margin model?
Classic SaaS has a marginal cost per user close to zero. Serving the ten-thousandth user costs roughly what the nine-thousandth did, so revenue growth flows almost straight to gross profit. AI features remove that property. Every request consumes metered compute, so cost scales with what each customer does rather than how many customers you have.
That breaks habits everyone learned from the last SaaS decade. "Growth at any cost" assumed the cost part was rounding error, and unlimited plans assumed nobody could consume enough to hurt you. Founders still anchor on the gross margins the last SaaS decade taught them to expect, then get startled when their own number comes back in the fifties.
So here's the position I'll defend for the rest of this post. Charging a flat rate for a variable-cost product is how AI companies grow into insolvency. Every signup makes the chart prettier and the bank balance worse. You won't feel it at 40 customers. You'll feel it at 4,000, which is when you've already hired against that revenue.
What actually goes into your cost per customer?
Cost per customer is the variable spend attributable to one account over a billing period, measured per account rather than as a company average. The model covers inference tokens both directions, failed and retried calls, embedding generation and regeneration, vector storage and queries, human review, egress, and evaluation runs.
Most teams count two of those nine. Pull one month of real numbers from your usage export and your own logs, and the true figure usually lands well above what you'd been quoting your board.
| Cost line | How to measure it | What people forget |
|---|---|---|
| Input tokens | Per-request counts tagged with account_id, from the API response metadata. | System prompts, few-shot examples and injected RAG chunks are input tokens too, often bigger than the user's question. |
| Output tokens | Same log, output field. Output typically prices higher than input. | Streamed answers a user abandons halfway still bill in full. |
| Retries and failed generations | Count total upstream calls, not successful ones. The gap is your waste rate. | Backoffs, timeouts, schema-validation failures, guardrail rejections, every "regenerate" click. All billed. |
| Embeddings and re-embedding | Tokens embedded at ingest, plus every full reindex. | The reindex. Change your chunking or swap embedding models and you re-embed every tenant's corpus at once. |
| Vector DB storage and queries | Index size per tenant in GB, plus query volume. | Storage bills whether the customer logs in or not. A churned account you never deleted is pure cost. |
| Context resent every turn | Average turns per conversation, times tokens carried forward each turn. | The quiet killer. In a 20-turn thread with no trimming, you pay for the opening messages twenty times. |
| Human review and support | Minutes of staff time per account per month, at loaded hourly cost. | "Why did it say that?" takes longer to resolve than a password reset, and review queues scale with volume. |
| Egress | Bytes out on your cloud bill, split by tenant where you can. | Trivial per request, brutal when customers export large artifacts. |
| Evaluation runs | Tokens burned by eval suites, regression tests, prompt and model A/B runs. | Your CI runs evals on every merge. That's your invoice, growing with your test coverage. |
Tag every upstream call with its account from day one, and keep tenant-level metering in the data model. That's far easier when your multi-tenant architecture was designed for per-tenant accounting. Retrofitting attribution later is a miserable quarter.
Why is your average user the wrong user to price for?
Usage on AI products follows a heavily skewed distribution rather than a normal one. A minority of accounts generate most requests, so the mean sits far below the top decile. Pricing built on the mean stays profitable for most customers and loses money on the heaviest, who are typically the most engaged and least likely to churn.
Run this on your own data. The numbers below are placeholders, invented for the demonstration and not from any vendor's price list:
Illustrative only. Plan price $49/month. All-in cost per request, including retries and retrieval: $0.011.
- Median account, 180 requests: costs ~$2. Margin on inference ~96%.
- Mean account, 340 requests: costs ~$3.70. Still comfortable.
- 90th percentile, 3,200 requests: costs ~$35. Add support and storage, you're near break-even.
- 99th percentile, 9,000 requests: costs ~$99. You now pay about $50 a month for the privilege of serving your favourite customer.
The mean said 92% margin. The mean was lying. What you need is a histogram of requests per account and a hard look at the right-hand tail.
Then check who's in that tail. Usually the design partners and reference customers, the people writing your reviews. Throttling them is a bad day. Pricing so their enthusiasm doesn't cost you money is a better one.
Which pricing model survives a variable cost base?
No pricing model is correct in isolation. Each aligns price with cost to a different degree and fails in a specific, predictable way. Flat and seat-based pricing decouple revenue from consumption entirely. Pure usage-based pricing tracks cost closely but makes bills unpredictable. Credit and hybrid models sit between the two.
| Model | How it works | Where it fails |
|---|---|---|
| Flat rate | One price, unlimited or effectively unlimited use. | No correlation between revenue and cost. Your heaviest users are your biggest losses, and heavy use correlates with loving the product. Insolvency arrives disguised as product-market fit. |
| Seat-based | Price per named user. | An agent doing the work of ten people is still one seat. Seat count stops tracking value the moment software does the doing instead of the displaying, and stops tracking cost immediately. |
| Usage-based | Metered per request, token, or completed task. | Margins are safe, adoption isn't. Buyers hate unpredictable invoices, procurement can't approve an unbounded number, and users self-throttle. |
| Credits | Prepaid bundle spent against actions. | Only works if the credit-to-cost ratio is honest and you re-price when models change. Credits also breed hoarding, where users stop experimenting. |
| Hybrid | Platform fee, an included allowance, then metered overage. | Complexity. Harder to explain on a pricing page, harder to forecast, more billing code. Also the most likely to actually work. |
I'd take the hybrid in most cases: a base fee covering fixed costs and support load, an allowance generous enough that ordinary customers never think about it, then transparent overage for the tail. Every complaint I've heard about metered pricing traces back to a bill that arrived without warning, not to the meter itself.
And price the outcome where you can. If one run replaces two hours of someone's work, that's your anchor, not your token cost. Cost sets the floor, value sets the price, and the gap is the business. Same argument as measuring AI ROI in delivered outcomes rather than model spend.
Which levers actually cut cost per request?
Five levers move cost per request materially: routing simpler tasks to smaller models, caching repeated context and identical requests, trimming prompts and retrieved context, batching non-urgent work through cheaper asynchronous endpoints, and cutting the retry rate. Together they usually compress spend more than any vendor negotiation will.
- Model routing. Classification, extraction, tagging and short rewrites rarely need your largest model. Route by task, measure quality on a real eval set, escalate only what fails. Normally the biggest single reduction available.
- Caching. Prompt caching on stable system instructions, plus an exact-match or semantic cache on repeated queries. Products with a narrow question space see high hit rates.
- Context trimming. Retrieve fewer, better chunks. Summarize old turns instead of resending them verbatim. Track average input tokens per request weekly and treat a rise as a regression.
- Batching. Anything the user isn't waiting on, including enrichment and scheduled reports, belongs on a batch endpoint where per-token rates are lower.
- Retry reduction. Constrain output with schemas, validate before regenerating, cap retries. A 20% failure rate means a fifth of your model spend produced nothing a customer saw.
Order matters. Route first, cache second, trim third. Teams that start by hand-optimizing prompts spend a fortnight recovering a few percent while the routing decision sat there worth ten times more.
What gross margin should an AI SaaS target?
Most AI SaaS businesses should aim for 60% to 80% gross margin at steady state, below the classic software benchmark but well clear of break-even. A lower margin is defensible when the product is early, when cost per request is falling faster than price, or when a strategic account buys you distribution. It stops being defensible once you raise on SaaS multiples.
Investors price software assuming revenue converts to gross profit at software-like rates. If yours converts at 45%, you're a services business wearing a SaaS badge, and someone notices during diligence.
A thin margin is fine in year one, while inference prices fall and your engineering hasn't optimized anything. It stops being fine eighteen months in, with no per-account instrumentation and a founder still quoting the average.
What guardrails should ship on day one?
Every AI product needs four controls before public launch: per-account rate limits, hard spend caps with graceful degradation, alerting on cost-per-account anomalies, and per-tenant cost attribution in your own dashboards. All four are cheap to build early and painful to retrofit after an incident.
- Per-account rate limits. Requests per minute and per day, tiered by plan. Your defence against a runaway script as much as an abusive user.
- Spend caps. A ceiling per account per period, with a degradation path that keeps the product usable: fall back to a smaller model, queue the work, or prompt an upgrade. Silent hard failure is the worst option.
- Anomaly alerting. Fire when an account's daily cost exceeds its trailing average by a wide multiple. The first sign of an integration stuck in a retry loop is a cost spike, not an error page.
- Cost attribution. Cost per account, per feature and per model, refreshed daily. If you can't see it, you can't price it.
- A kill switch per feature. One flag that disables an expensive capability without a deploy.
None of this is exotic engineering. It's a week of work at the start and an ugly quarter if you skip it, which is why we build metering into the foundation on SaaS platforms we build for founders instead of treating it as phase two.
The short version
Build the cost table, pull a month of real per-account data, and study the right-hand tail instead of the mean. Then pick a pricing model that moves when your costs move, and ship the guardrails before the launch. If you want a second pair of eyes on the model, book a 30-minute call and bring your numbers.
Frequently Asked Questions
What is a good gross margin for an AI SaaS?
Aim for 60% to 80% at steady state. Below 50% means your pricing or your architecture needs work. Above 80% usually means you've routed and cached well, or your AI component is lighter than the marketing suggests.
How do I calculate cost per customer from one aggregate provider bill?
You can't, and that's the first thing to fix. Log every upstream call with an account identifier, token counts both directions, model name, and success or failure. Reconcile your logs against the provider invoice monthly.
Should I move from flat pricing to usage-based?
Rarely as a straight swap. Move to a hybrid: keep a base fee, add an allowance sized so most current customers see no change, meter above it. Show consumption in-product for a full cycle before any bill changes.
Do credits fix the heavy-user problem?
Partly. They cap your exposure per period, which is the main thing. They don't fix a broken credit-to-cost ratio, and they need re-pricing whenever you change models, because a credit that cost you a cent last quarter might cost four now.
Is self-hosting an open-weights model cheaper?
Sometimes, at high steady volume. You swap a variable per-token cost for fixed GPU capacity plus engineering time, so the crossover depends on utilization. Spiky traffic on reserved hardware costs more than an API.
If I track one number, what should it be?
Gross margin on the 90th-percentile account, monthly. The average tells you nothing you'll act on. The tail tells you whether your pricing survives success.
Have a project in mind? Let's scope it together.
You get a named team, written estimates, full code and IP ownership, and 48-hour response times. CMMI Level 5 certified. 700+ projects delivered across the UK, US, UAE, and Australia.
