SAAS OPERATIONS
AI SaaS Unit Economics: How to Price Your Product Without Losing Money on Heavy Users
String AI
· 10 min read ·
A $29 subscription looks straightforward on a pricing page. It becomes harder to reason about when one customer asks for a few short summaries and another runs a research agent throughout the working day. Both pay the same amount. Their costs can be very different.
That difference deserves attention before you advertise an unlimited plan. A useful customer can be expensive precisely because they use the product for serious work. If you have priced the plan around occasional usage, your most engaged customers may outgrow its economics before they outgrow its features.
AI SaaS unit economics starts with a specific question. After serving this customer for the billing period, how much of their revenue remains to pay for acquiring customers, building the product, and running the company? Answering it requires a record of completed work, a view of expensive users, and billing rules that match what you can afford to deliver.
Choose a unit that describes the work
Start with something the customer recognizes. An account-month tells you whether a subscription is sustainable. A completed task tells you which part of the product makes that subscription expensive.
For a document product, the task might be processing one uploaded document within a defined size limit. For a support product, it could be a resolved conversation. A research agent might produce a report with a stated scope and source limit. These definitions will change how you measure costs and describe allowances.
A raw request count is often too coarse. One click may trigger a planning call, several searches, another model call to interpret the results, and a final answer. It can also trigger retries. The customer still sees a single report.
Give that report a task ID. Attach every related provider charge to it, including charges from attempts that never produced a usable result. If you promise to charge customers only for successful reports, the failed attempts still need to fit inside your economics.
You can then calculate cost per successful task by dividing the total delivery cost of a task cohort, including unsuccessful attempts, by its successful completions. Keep unfinished work separate until it succeeds or reaches its stopping rule. Otherwise, long-running jobs can disappear from the calculation simply because they have not finished yet.
Build a cost record before adjusting the price
An inference log should let you connect an account and billing period to the task that incurred a charge. Record the model, its version where available, the usage reported by the provider, and the applicable rate. Keep the provider request ID so that you can reconcile your calculation with the invoice later.
Separate ordinary input from cached input and output wherever the provider exposes those categories. Cache writes can have their own pricing too. OpenAI's prompt-caching documentation explains that reuse depends on a matching prompt prefix and that the pricing and cache behavior vary by model generation.[3] Applying a best-case cache discount to every request will make a forecast look better than the bill.
Add retrieval and other paid tools to the task record. Include storage or processing charges attributable to the work. A voice application needs a place for transcription and speech generation; a report builder needs a place for its paid data sources. The LLM invoice alone does not describe the cost of delivering either product.
A practical reporting table can stay small.
View | What it helps you decide |
|---|---|
Cost per successful task, grouped by feature | Which workflow needs engineering attention |
Monthly delivery cost per account, grouped by plan | Whether a plan covers the work it permits |
Upper-percentile costs and the most expensive accounts | Which usage patterns need a separate allowance or plan |
Cost of failed and retried work | How much reliability problems consume |
Revenue and delivery contribution by acquisition cohort | Whether new customers resemble the ones you priced for |
Use aggregate usage metadata wherever it is enough. Cost reporting rarely needs a permanent copy of a customer's document or full conversation.
A worked example of the heavy-user problem
Consider a deliberately simplified $29 monthly plan. The figures below are illustrative assumptions, not a provider quote or an industry benchmark. Revenue excludes sales tax. Assume $1.50 in payment and billing fees and a $0.50 allowance for refunds or payment losses per account-month. Assume, for simplicity, that these allowances are the same across the usage groups.
Here, delivery cost includes inference, paid tools, and the variable infrastructure and support allocated to the account. Delivery contribution is revenue less those delivery costs and the payment-related allowances. It is a planning metric, not an accounting gross-margin statement; your accountant may classify some of these items differently.
Monthly account profile | Revenue | Payment and loss allowances | Delivery cost | Delivery contribution |
|---|---|---|---|---|
Light usage | $29.00 | $2.00 | $3.00 | $24.00 |
Regular usage | $29.00 | $2.00 | $12.00 | $15.00 |
Heavy usage | $29.00 | $2.00 | $38.00 | -$11.00 |
If light users make up 70% of accounts, regular users 25%, and heavy users 5%, average delivery contribution is $20.00 per account-month. The overall plan appears comfortable. The heavy group still costs more to serve than it pays.
That may be acceptable for a small, deliberately supported group. It becomes a different decision if your next acquisition channel mostly attracts those users. A community of researchers could use a report-generation product very differently from the occasional users who joined during a general launch.
Compare new cohorts with the assumptions behind the plan. If costs rise because customers are completing more valuable work, consider packaging that work differently. If costs rise because the agent repeatedly fails the same task, fix the failure before charging more for it.
Turn the cost record into understandable allowances
Customers should be able to estimate what they can accomplish before they buy. A plan with a clear document allowance and size limit is easier to evaluate than an unexplained balance of credits.
Credits can still work when features have different costs. Show what common actions consume, explain whether unused credits expire, and give users advance notice before they run out. Keep those rules visible in the product as well as on the pricing page.
Decide what happens at the allowance boundary. You might pause work, offer a prepaid top-up, or ask for approval before charging overages. Avoid an automatic paid continuation that the customer discovers on the next invoice. Long-running jobs deserve a budget check before they start and a clear stopping condition while they run.
Bound the work inside each unit too. A report allowance needs limits on its research scope. A document allowance needs limits on input size. Without those boundaries, a single nominal unit can conceal a large difference in cost.
Heavy users may be good candidates for a higher-volume plan, but the price has to cover the discount and the workload. Look at their actual task mix before offering a larger allowance. A customer processing short forms and a customer analyzing lengthy reports do not necessarily need the same package.
Treat the free trial as a separate cost decision. Let prospects complete enough meaningful work to evaluate the product. Set an account-level budget for the trial and review abuse without forcing legitimate buyers through unnecessary checks. Include trial-serving costs when assessing what it costs to acquire a paying customer.
Reduce delivery cost without making the product worse
Begin with the expensive task records. They tell you whether the problem is a costly model, excessive context, repeated failures, or too much work being attempted in a single run.
For model selection, test the same representative tasks against a small set of candidates. Include awkward inputs from the product's real use cases, with appropriate permission or anonymization. Decide what a passing result looks like before comparing prices. A cheaper model that needs repeated corrections may have a higher cost per usable result.
A multi-model service such as String AI gives teams an option for accessing different models through a shared service.[1] When evaluating that approach, check the available models and actual account rates against your workload. Consolidated access can make experiments easier to manage; the savings still have to appear in your own results.
Keep model-specific differences in the test. An OpenAI-compatible interface does not guarantee identical tool behavior, context limits, or response fields. The String AI API integration documentation provides its base URL and authentication details as a starting point for integration.[2] Run representative tasks through the specific models you intend to offer before making a production commitment.
Context is another place to inspect. Check whether the application resends material that the next step does not need, or retrieves far more text than the answer uses. Shared instructions may benefit from prompt caching where supported, but base your forecast on measured usage categories and observed cache reuse.[3]
Set a finite retry budget. Retrying a transient failure can be worthwhile; repeatedly submitting an impossible task is wasteful. Record why a run stopped so that customer support can distinguish an exhausted budget from an unsupported input or provider outage. Give the user a useful explanation and a way to revise the request.
Connect the usage record to the money received
Customer billing and inference billing describe different events. Your application has to connect them.
Anyway offers hosted checkout, subscriptions, and Merchant of Record services for global sales, including handling transaction taxes and invoices within its service scope.[4] Those services address the collection side of the business. Your application still needs to know which account bought which plan, what work that plan allows, and how the allowance changes when a subscription renews or ends.
Use verified payment events and the provider's documented state transitions to update those entitlements. Make event processing idempotent so a repeated notification cannot grant the same allowance twice. A browser arriving on a success page should not be sufficient evidence to unlock an expensive workload.
Reconcile the period's orders with refunds, provider fees, and payouts. A payout can differ from the revenue earned during the period because of timing, reserves, or adjustments. Deduct a fee only once: if your starting amount is already net of that fee, do not subtract it again. Transaction taxes collected for remittance should not inflate your view of available revenue. Other tax and accounting obligations still depend on your business and jurisdiction.
Review cash separately when offering annual plans. Collecting payment upfront gives you cash before you incur all the delivery costs, but it also commits you to serving the customer for the covered period. A long subscription discount needs room for that future usage.
Review the plan when the workload changes
Bring the cost report into the same review as feature releases and pricing. A new research mode can alter cost per task. A model change can alter both quality and retry rates. A promotion can attract a different mix of customers even when the product itself stays the same.
Start with the accounts whose costs depart most from the plan's assumptions. Read their task patterns before deciding whether to change the allowance, the implementation, or the price. Some will be paying customers with a valuable workload worth supporting through a larger plan. Others will reveal a bug you would rather find before the next renewal cycle.
Before expanding acquisition, write down how much work the plan includes, what happens when that work is used up, and what it costs to deliver at both ordinary and heavy usage. Then make sure the product enforces the rules you have put on the pricing page.
Contributed by [String AI](https://www.string.ink/), a multi-model AI access platform for individuals, developers, and teams. This guest article was prepared for Anyway.
Sources
[1] https://www.string.ink [2] https://www.string.ink/docs [3] https://platform.openai.com/docs/guides/prompt-caching [4] https://anyway.sh