Chapter 12: The economics of an AI feature

Overview#

Take two products. One charges businesses for each document it successfully processes. The other sells a flat monthly subscription and lets customers run an AI assistant as often as they like.

They use the same models at the same negotiated API prices, yet their financial results can differ sharply.

For the document product, revenue grows with completed work, provided price and direct cost stay in proportion. For the subscription product, a few very active accounts may generate most of the inference spend while paying the same as everyone else.

Here cost optimization becomes a product-economics problem as well as an infrastructure one. You need to know which customer action creates value, what it costs to serve, and how revenue changes as usage grows.

Keep the gross margin of the whole company separate from the contribution margin of one AI feature. The second is a decision tool: it can show which usage patterns are sustainable before company overhead and other accounting choices are included.

Practical#

Start with the billable or valuable unit#

For a document processor, the unit might be one accepted document; for a research agent, one completed report; for a coding product, one accepted task. For an AI assistant sold as part of a larger SaaS product, the relevant units may be cost per active account per month and cost per useful interaction.

Use at least two views of the economics:

Net revenue means revenue after applicable discounts, credits and refunds, rather than a marketing list price. Serving cost should include inference, paid tools, variable infrastructure and expected human correction. If you allocate shared fixed capacity, label that allocation separately so the variable margin doesn’t get mixed up with fully allocated unit cost.

A subscription can conceal expensive users#

A hypothetical AI product charges €49 per account per month, excluding taxes. Its usage is distributed like this:

At 1,000 paying accounts, subscription revenue is 1,000 × €49 = €49,000/month. AI serving costs are €9,350, or about 19.1% of revenue, which looks manageable in aggregate.

The fifty heavy accounts, however, generate €4,250 of cost against €2,450 of revenue. Their AI-serving contribution is negative €1,800 before customer support and other expenses, and the other accounts subsidize them.

Heavy users can still be worth having, since they may retain longer, refer other customers or upgrade later. Even so, treat the subsidy as an explicit pricing and capacity decision. An average across all accounts hides this tail, as an average across agent tasks does.

Decide who carries the usage risk#

Pricing models distribute risk differently:

Credits need care. One “credit” might represent a model call, a fixed number of tokens or an abstract unit of work. If underlying model costs change, what a credit is worth economically can drift unless the entitlement is clear and versioned.

It often works to meter valuable work at the product layer and track tokens underneath as a cost driver. Customers understand a processed document or a completed report more easily than internal reasoning-token accounting. Task size isn’t always stable, though, so the product may need tiers or fair-use rules for unusually expensive work.

A unit-economics worksheet#

Suppose a research-report feature has these hypothetical characteristics:

• Net revenue attributable to one completed report: €2.50.
• Average inference and tool cost per submitted report: €0.90.
• Acceptance rate: 80%.
• Additional expected review and delivery cost per accepted report: €0.30.

To deliver 100 accepted reports at an 80% acceptance rate, the simple expected submitted volume is 100 / 0.80 = 125, assuming the rate is stable.

Estimated inference and tool spend is 125 × €0.90 = €112.50. Add 100 × €0.30 = €30 in review and delivery costs: €142.50 total, or €1.425 per accepted report. Against €2.50 in revenue, contribution is €1.075 per accepted report before other allocated costs.

Comparing the €2.50 price only with the €0.90 per submitted task overstates the margin, because rejected and incomplete attempts are part of the cost of delivering accepted work.

The worksheet reproduces this calculation and the sensitivity table in the Deep Dive.

Ledgerline. Ledgerline sells research reports inside a $299 monthly plan. Each accepted report now costs $0.28 in inference ($560 / 2,000). Thirty of its 400 accounts generate 1,200 of the 2,000 monthly reports, 40 each, or $11.20 of inference per account: well inside the price. To keep that true if heavy accounts automate daily reports, the plan now includes 200 reports a month ($56 of inference) and charges for more.

Deep Dive#

The margin changes when the product changes#

An AI application’s cost distribution is rarely fixed. Adding tool access can turn a cheap assistant into a multi-step workflow. A larger context window may change prefill spending. Better model quality can reduce retries but raise per-call cost. A new enterprise customer may send larger documents or have much higher peak concurrency than existing users.

Track each account cohort on net revenue, accepted work, variable AI serving costs, paid tool usage, the fraction of users triggering fallbacks and P95 account-level spend. Revenue per account alone won’t show a cohort drifting into the heavy-user tail.

Marginal usage still costs capacity on a flat-rate plan#

Under a flat-rate plan, an extra eligible request may not raise the monthly bill directly, but it still occupies throughput. It could affect latency for other users or require a higher tier. A product with unlimited customer-facing usage can therefore consume capacity quickly while vendor invoicing stays predictable.

Keep a capacity view next to the financial one. The invoice explains current spend but won’t tell you whether the operating model can support additional demand.

Avoid using a cost metric as a product KPI#

Cost per accepted task can be optimized in ways that make the product worse. Acceptance rules strict enough that almost nothing qualifies make unit economics look terrible, and rules that accept every response make them look wonderful. Neither tells you whether customers got what they wanted.

Tie acceptance to real product outcomes where possible. For a tool used by employees, account for human time saved or lost. For a customer-facing feature, track whether the result was usable, whether another run was needed and whether users still value the feature. Some of these signals won’t convert into precise dollar figures; leaving them out makes the numbers look more certain than they are.

Run the worksheet through a sensitivity table#

Take the research-report worksheet and vary two inputs: the acceptance rate and the inference and tool cost per submitted report. Net revenue stays at €2.50 and review at €0.30 per accepted report.

Illustrative scenario arithmetic based on the worksheet above, before allocated costs.

A cost rise from €0.90 to €1.20 per submitted report cuts contribution at 80% acceptance from €1.075 to €0.700. A drop in acceptance from 80% to 60% does the same at today’s price. If both happen, €0.20 is left, 8% of revenue. Add rows for the inputs your product is most exposed to, such as a premium tool’s share of tasks, and one for the usage level you are planning for.

Further reading: AWS Well-Architected: Cost Optimization, Stripe: Usage-based billing.