One $20 plan, two users, opposite results. In the illustrative numbers below, the light user earns you $16 a month and the heavy one costs you $14. Classic SaaS never had that problem, because one more user cost almost nothing to serve. An AI product pays for computing power (inference) on every request. So the business model has to decide who pays that bill, and modelling unit economics before scale is how you find the margin nobody checked.
AI margin has to be engineered, because the market will not hand it to you
Four pressures act on every AI business model at once.
- Cost per request. Every request costs computing power. Bigger models cost more. Without limits, each very active user eats into your margin.
- Everyone has the same models. The big AI models get better every month, and every competitor uses the same ones. You stand out only through industry knowledge, your own data or being built into the customer's daily work.
- Constant improvement. Buyers expect the product to keep getting better. Retraining models and collecting feedback become a permanent cost.
- Fragile trust. Made-up answers, quality that slips over time and uneven results hit retention and how much customers think the product is worth.
A model that captures revenue but ignores variable load looks healthy in a pilot. At scale it falls apart.
The gap with software shows up in three cost lines a SaaS founder rarely budgets: compute that scales with every request, human work on data and evaluation, and customisation that differs per customer. Each of them grows with usage, so gross margin depends on who uses the product and how hard.
Foundation-model prices have been falling fast, and the cost of equal capability keeps dropping with each model generation. That helps, but it does not settle the question. A tenfold drop in unit price is worth little if heavy users consume twenty times more. So every point of margin still has to be engineered, and the founder's real question is which cost lines the pricing makes the customer share.
Six business shapes, and the pressure each one leaves exposed
Each workable shape answers those pressures in its own way. None answers all four.
Usage-based pricing charges for what actually costs money: words processed (tokens), API calls, documents, minutes of computing or AI actions inside a workflow. The price moves with your cost to serve the customer. Revenue grows as the customer uses more, and nobody has to renegotiate before trying something bigger. That makes it cheap for the customer to experiment, which is what you want early on.
The downside is that nobody can predict the bill. Customers struggle to forecast spend, which slows down buying at large companies. The vendor gets revenue that rises and falls with the workload. So usage pricing needs tight cost control. Reusing earlier answers (caching), sending simple requests to cheaper models and running jobs in bulk belong in the margin plan, not only in the engineering backlog. Providers price cached context and delayed batch jobs well below live requests, and the lever is large: if a third of your traffic can run as overnight batch work at half price, the inference line falls by about a sixth. Run pricing tiers and inference-cost curves through a unit-economics calculator before a new tier ships.
Subscription-plus-usage hybrids pair a base fee and an included allowance with metered overages. The structure is simple. All the design work sits in the allowance. Set it too generous and heavy accounts quietly erode margin. Set it too tight and customers throttle their own usage, the opposite of what a growing product needs. The shape fits writing tools, search and retrieval, and vertical assistants for legal, healthcare or engineering teams: buyers want a predictable line item even when usage varies month to month.
Outcome and workflow pricing sells results: hours saved, tasks automated, cases resolved, leads qualified, fraud prevented. It moves the conversation onto the buyer's terms. Nobody in a finance review argues about token counts, but everyone understands cases resolved per month. The price also survives model changes. If inference cost halves next quarter, the value delivered does not, and neither does the invoice. The catch is measurement. You must be able to see the result, prove your product caused it and leave little room for dispute. When that works, customers tend to stay longer and bring in more over time than with any other shape here.
Industry-specific AI platforms win on special data, knowledge of the industry and deep integration. Raw model quality matters less. Revenue comes from paid data access, models trained for one industry, compliance packages and assistants tuned to the field. A general competitor cannot copy this by plugging in a better model. Data, a place in the customer's daily work and trust take years to build. The price of the position is a smaller market and a longer sales cycle. That trade is reasonable when willingness to pay is high.
Data-network models earn money from the data and insights that users create. They charge for platform subscriptions, premium analytics and model improvements. The loop matters more than the price list. Each new customer makes the model better, and that makes the product better for the next one. Over time this builds a lead that pricing alone never could. But until the loop gets going, the model is weak, which is why it rarely works as a company's first business model.
Model-as-a-service sells tuned or cheaper-to-run models through an API. The winner is usually the model that fits the job: small and fast for devices, special versions that meet the rules for health, legal and finance, setups built for privacy, or cheap stand-ins for the big general models. The buyer is technical and can easily compare offers. Latency and uptime commitments are part of the product, and a provider that cannot state its cost per thousand calls loses to one that can.
No shape is universally best. Most mature AI companies combine them: a subscription to lock in base value, usage or outcome pricing to capture the increment, and enterprise contracts to cover security and compliance.
Contribution margin per customer decides whether the model is fundable
Cost-to-serve is the number that decides whether the rest holds. For AI it changes with every request. It covers running the model, hosting and graphics cards, search over your own data, memory, caching and bulk processing, and the safety and moderation checks that never show up in a demo.
The formulas are short:
- Contribution margin = revenue per customer minus cost-to-serve.
- Cost-to-serve = inference + hosting + embeddings and retrieval + safety layers.
- Margin % = contribution margin / revenue per customer.
- Payback months = acquisition cost / monthly contribution margin.
Model it across usage levels. A single average account hides exactly the accounts that sink the plan.
A worked example: why a flat price breaks on heavy users
Take a flat $20/month plan with no usage cap and two accounts on that price:
- Light user: modest workload. Cost-to-serve ≈ $4 (inference $2.50 + hosting, embeddings and safety $1.50). Contribution margin = $20 minus $4 = $16, about 80%.
- Heavy user: roughly 15× the workload on the same fee. Cost-to-serve ≈ $34 (inference $28 + $6 fixed overhead). Contribution margin = $20 minus $34 = -$14.
The heavy account runs at a loss. Many light users keep the blended average healthy, until the mix shifts. Say the base is 90 light users and 10 heavy ones: blended contribution is $1,440 minus $140, about $1,300 a month, or 65%. Move to 70 light and 30 heavy and it falls to $1,120 minus $420, $700, or 35%. Revenue did not change. More sales of the same plan only deepen the hole.
Here is the fix in the same numbers. At heavy volume, inference runs about $1.87 per unit of light-user workload ($28 across 15 units). Cap the $20 plan at four units: about $7.50 of inference plus roughly $2 of overhead puts cost-to-serve near $9.50, a margin around 52%. Bill each extra unit at $2.50. The heavy account now pays $20 plus 11 extra units, $47.50 in all, against a $34 cost. A $14 loss becomes a $13.50 contribution. The light user notices nothing, since one unit sits well inside the allowance.
Where each pricing shape breaks, in the same numbers
The worked example gives enough to compare the shapes on one axis: how heavy, or how light, an account can be before it stops paying for itself. Take inference at about $1.87 per unit of light-user workload and $2 to $6 of fixed overhead per account per month.
- Flat plan at $20. Contribution hits zero when inference reaches $14 to $18, somewhere between 7.5 and 9.6 units. Any account running about eight times the light workload is served at a loss, and nothing in the plan stops it from getting there.
- Per-seat plan at $20 a seat. The same break-even applies per seat, with a twist: as AI does more of the work, fewer seats carry more usage each, so seat count falls while cost per seat rises. The plan drifts toward the loss line on its own.
- Hybrid: $20 with four units included, $2.50 per extra unit. It never breaks on heavy users. Each extra unit adds about $0.63 of contribution, so the heaviest accounts become the most profitable in dollars, though the margin on overage is only about 25%.
- Pure usage at $2.50 per unit, no base fee. It breaks at the other end. With $2 of fixed overhead, an account needs about 3.2 units a month just to cover it, so the long tail of occasional users runs at a loss.
- Outcome pricing, say $3 per resolved case. The break-even is measured in compute per outcome. A case that needs one unit earns about $1.13; a hard case that needs two units loses about $0.74. The plan holds as long as the mix of hard cases is known and stable.
Read that way, the choice of shape is a choice of which tail you are willing to carry. Heavy-usage products need the hybrid or outcome shape; products with many occasional users need a base fee.
Unit prices are an input you do not control, and they move both ways. Per-token prices have mostly fallen. Yet in August 2026 DeepSeek raised API prices for its V4 models by between 50% and 1,100%, depending on the model, the token type and the time of day. A cost model that assumes today's price for three years is a forecast with one scenario.
Run three: current price, plus 50%, plus 100%. In the worked example, plus 100% on inference lifts the capped plan's cost to about $17, and margin drops from 52% to roughly 15%. If contribution margin turns negative in the third scenario, the contract needs a model-substitution right or a repricing clause before anyone signs.
Lifetime value follows from usage revenue, retention, gross margin and expansion. AI products often expand strongly once a workflow is embedded and switching hurts. Against acquisition cost, a three-to-twelve-month payback is a rule of thumb with no study behind it. David Skok's "SaaS Metrics 2.0" puts the SaaS benchmark at LTV of at least 3x CAC and payback near 12 months. Those numbers assume near-zero marginal cost, so for an AI product they are the best case.
The 15x workload and the effect of the allowance on behaviour are both assumptions; a quarter of billing data will replace them with real numbers. If your most active customers are your least profitable, the model has a structural flaw that repricing or limits must fix before you scale.
Build the model in the order the numbers demand
Each step constrains the next, so the order is the method.
- Map where AI creates a measurable outcome; an impressive output is not enough.
- Choose the monetization axis that fits it: usage, workflow, subscription, hybrid or vertical.
- Cost the whole pipeline: inference plus embeddings plus safety layers, so the price can clear them.
- Define the value metric the customer recognises: tasks automated, speed, accuracy, compliance.
- Run scenarios across tiers, usage volume, model size and cost curves to see where margin breaks.
- Tie expansion to added value, then test it with real behaviour.
Step six is where models usually fail. Expansion rarely comes from a second signature. It comes from more usage inside the first one: higher tiers, more seats, larger allowances, add-ons, vertical modules. Each should read as added value to the customer. Lifting a limit you invented reads as a toll.
And the model on the slide stays a hypothesis until behaviour confirms it. Pricing experiments show where willingness to pay stops. A/B tests compare packagings of the same capability. Cohort analysis shows whether a price change moved retention over months, which a single week of conversion data cannot. Most packaging ideas will move nothing measurable, because buyers anchor on the first price they saw, so budget for several rounds.
Three startups, three different answers
None of the three below is a real company; each is a pattern assembled from common cases. They show how the same ordering lands in different places.
A productivity startup sells document automation on a subscription with usage add-ons. It measures value in hours saved. That framing sustains retention: once a team rebuilds its approval process around the product, a cheaper rival is not a serious alternative. Stable retention then produces forecastable lifetime value.
A vertical healthcare startup ships HIPAA-compliant assistants on domain-specific models. The market is narrower. Premium pricing rests on regulatory and accuracy advantages a generic assistant cannot claim, and willingness to pay comfortably covers cost-to-serve. The binding constraint is sales-cycle length; gross margin takes care of itself.
An API-first startup sells inference endpoints to financial institutions and bills per transaction. Expansion needs no new contract: as client volume grows, so does revenue. The mirror image is volatility. When one client pauses a project, the drop lands in that month's revenue. A simple guardrail follows: if one client brings more than a quarter of monthly volume, price a minimum commitment into its contract.
The three answers differ for a reason. The productivity startup prices the outcome because hours saved are easy to count. The healthcare startup prices the risk it removes because compliance is what the buyer fears. The API startup prices the transaction because its buyer already thinks in transactions. In each case the unit on the invoice is the unit the buyer already reports upward.
Flat pricing wins in two cases, and per-seat pricing in almost none
Most pricing regrets trace back to one habit: treating an AI workload like SaaS. A per-seat price collapses margin as usage climbs. The seat that runs fifteen times the workload, like the heavy account above, pays exactly what the light one pays. Ignore how model costs move, and every new customer makes scaling more destructive. Skip the worst-case scenario, and the business is exposed at the moment load spikes.
Flat pricing has real defenders, and procurement is the loudest. It prefers a fixed line item it can approve once a year, and a predictable invoice can save a deal a whole budget round. It holds up in two situations:
- usage is narrow: your heaviest decile runs under three times the median workload;
- inference is so cheap that your heaviest plausible account costs less than a tenth of its fee.
If either holds, keep the flat plan and spend the effort on retention. If neither does, the flat plan is a bet that your best customers stay small.
Two more regrets are about language. One is shipping without a clear value metric. The other is assuming customers understand tokens or model sizes. They care about outcomes. Tokens are a developer's unit: developers already think in calls and can forecast consumption, end users cannot. Once price is tied to a task or an allowance instead of raw compute, the two decouple, and a gain in caching or routing shows up as margin rather than a smaller invoice.
Each funding stage moves the pricing lever
Before product-market fit, learning speed beats margin. Use simple usage or workflow pricing you can explain in one sentence, and iterate. Customers reveal the real value metric through what they complain about and what they expand. Keep models small on purpose: that holds cost-to-serve in a range you can absorb while the usage pattern is unknown.
Around Series A, standing out starts to pay. Plan tiers and features for large companies separate the customers who will pay more from the price-sensitive ones. You now build your data advantage on purpose, by getting deeper into customers' daily work. The habit to build here is rhythm: check margins every quarter, before a group of customers quietly turns unprofitable.
After that, the biggest gains come from infrastructure, not pricing. Caching and picking the right model for each request go straight to gross margin. Versions for neighbouring industries widen the business. Quality checks get automated, so output stops depending on manual review.
Each stage also has a typical failure symptom. Before product-market fit it is a pricing page with five tiers and twelve customers. Around Series A it is a gross margin that drifts down two or three points a quarter while revenue grows. Later it is a routing project that keeps slipping because no one owns margin as a number.
Founders arriving from SaaS need one point spelled out. There, another user costs roughly nothing. Here inference cost and memory constraints belong in the model from day one, and a price that leaves them out is a quiet bet that usage stays low.
Before raising prices or adding a plan, answer five questions with a number:
- What is contribution margin for each of your ten heaviest accounts?
- How many times the median workload does your heaviest decile run?
- What happens to margin if inference prices double?
- Which value metric would the buyer's finance team recognise?
- Does the contract allow model substitution or repricing?
The decision rule: if any of the ten heaviest accounts shows negative contribution margin, the next pricing change is a usage tier or an allowance, never a discount.