Shipping AI Features Without Wrecking Your Unit Economics

Conventional software has a comforting property: serving one more user costs approximately nothing. Build it once, and the marginal cost of the next request rounds to zero. Every instinct in SaaS pricing is built on that assumption.

AI features break it. Inference has a real per-request cost that scales linearly with usage. Which produces an outcome founders do not expect and rarely model: the more successful the feature, the more money it can lose.

This is not an argument against building them. It is an argument for knowing the number before launch instead of discovering it in a billing dashboard three months later.

The arithmetic that catches people out

Work it through with any AI feature you are planning. Take your per-request inference cost, multiply by how many times a typical user triggers it per month, and compare that with what a user pays you per month.

That single line of arithmetic is enough to kill a surprising number of feature designs, and it costs an afternoon to do. The failure modes are consistent:

• A flat-priced plan with an unlimited AI feature. Your heaviest users are usually your most enthusiastic advocates, and they are the ones losing you the most money.
• A free tier with the AI feature included. Free users have no revenue to offset against, so the cost is pure. Rate limits are not a detail to add later; they are part of whether the tier is viable.
• An agent that loops. One user action triggering a chain of model calls multiplies cost by the chain length, and chains have a habit of getting longer as the feature gets smarter.

A feature that costs more per user than the user pays does not become profitable at scale. It becomes a larger loss at scale.

What drives the number

Four things, roughly in order of how much use they give you.

How many calls one action makes. The single biggest lever, and the most often overlooked. A feature designed as "analyse the document, then summarise each section, then synthesise" makes one call per section plus two. Redesigning it to make one call with a structured output can cut the cost by an order of magnitude, and usually cuts latency too.

How much context you send. You pay for input tokens on every request. A long system prompt, a full conversation history, or twenty retrieved documents are all paid for every single time. Trimming context is unglamorous and immediately effective.

Which model you use. The spread between model tiers is large. The mistake is treating this as one global decision: most products have a mix of easy and hard tasks, and routing the easy ones to a smaller model while reserving the capable one for hard cases is where a lot of the savings live.

Whether you cache. Many products issue near-identical requests repeatedly. Caching identical requests is straightforward; caching a shared prompt prefix is often supported directly by the provider and costs little to adopt.

The design decisions that are really cost decisions

This is the part that belongs in the product conversation rather than the engineering one, because the highest-use choices are made before any code exists.

Automatic or on demand? Running a generative step on every upload feels frictionless and charges you for every upload, including the ones nobody looks at. Running it when the user asks costs you only the ones that were wanted. The frictionless version is usually the right product call for a premium tier and the wrong one for a free plan: same feature, different economics.

Every item, or a selection? "Summarise all my documents" scales with the customer's library size, which you do not control. "Summarise this document" scales with intent, which is self-limiting.

Live, or precomputed? Some outputs change rarely. Generating once and storing turns a per-view cost into a per-change cost, and for anything read more often than it is edited that is an enormous difference.

Does it need a model at all? The most effective cost optimisation remains deleting the model call. Classification with a fixed set of labels, extraction from consistently-formatted documents, routing rules. These are frequently better served by ordinary code, which is faster, free to run, and testable. Part of what an experienced team is for is saying so, as we argue in what AI-native product engineering changes.

Latency is the same conversation

The choices that reduce cost mostly reduce latency too, because both scale with the number of calls and the volume of context. That alignment is convenient, and it is worth noticing when it breaks: a smaller cheaper model that needs three attempts to get the answer right is worse on both axes than one call to a capable one.

Where latency cannot be removed, it becomes an interface problem. An eight-second generation is a different feature from an instant one, it needs streaming, or progress, or an async pattern where the user is told when it is ready. That is design work, and it is cheaper to do at the wireframe stage than to retrofit into a screen that assumed instant.

Pricing models that survive an AI feature

If the arithmetic does not work, the answer is not always to cut the feature. Often it is that flat pricing was the wrong container for it. Four structures, with the trade-off each carries:

Usage-based. Charge per unit of the expensive thing — per document analysed, per report generated. Costs and revenue move together, which removes the risk entirely. The cost is commercial rather than technical: buyers dislike unpredictable bills, and it can suppress exactly the exploratory usage that gets people hooked.

Credits included, then top-ups. A plan includes an allowance, heavy users buy more. This is the most common resolution because it keeps a predictable headline price while capping your exposure. The design work is in setting an allowance that covers ordinary use comfortably: an allowance most users hit is experienced as a bait and switch.

Tiered by capability. The expensive feature belongs to a higher tier. Simple to explain and to build, and it turns the cost problem into an upgrade prompt. Works when the feature is a premium capability rather than something the product feels broken without.

Flat pricing with honest limits. Keep one price, apply a fair-use ceiling, state it plainly. Viable when your worst case is bounded and small. It fails silently when nobody models the worst case, which is how most unlimited AI features get quietly withdrawn.

The one to avoid is unlimited access to an unbounded feature on a flat plan. It is the structure that makes your best customers your biggest losses, and it is very hard to walk back once people have bought it.

When the honest answer is not to build it

Sometimes the arithmetic simply does not close: the feature costs more per user than the segment can pay, at any plausible price. That is worth naming as an outcome rather than treating as a problem to engineer around.

Before abandoning it, three things are worth testing, because they frequently change the answer:

• Does it have to run on everything? Applying it to what the user selects instead of their whole library often turns an unbounded cost into a bounded one.
• Does it have to be generative? A large share of what gets specified as an AI feature is classification, extraction or routing wearing a costume. Ordinary code is free to run and easier to test.
• Does it have to be live? Precomputing on change rather than on view collapses the cost for anything read more than it is written.

If none of those help, a feature that loses money at scale is a strategic decision rather than an engineering one, and it should be made deliberately by someone who owns the P&L. What it should not be is discovered by accident in month four.

Instrument it from day one

You cannot manage what you cannot see, and provider dashboards give you a monthly total, which is exactly the wrong granularity. Log, per request: which feature triggered it, which model, input and output token counts, and the user or account. Aggregate that into cost per feature and cost per account.

That data answers the questions that come up. Which feature is eating the budget? Which customers are unprofitable? Did last week's prompt change make things cheaper or just slower? Without it, every one of those is guesswork, and the first time anyone looks closely is when finance asks about the bill.

Adding this later means reconstructing months of history you did not record. It is a day of work at the start, so it is part of the backend foundations rather than a later addition.

The questions to answer before you build

• What does one invocation cost, at the model and context size you plan to use?
• How many invocations will a typical user make per month? And your heaviest one percent?
• What does that user pay you per month?
• If the answer to 3 is smaller than 1 × 2, what changes? Pricing, rate limits, the design, or the decision to build it?

None of these require the feature to exist. All of them are much harder to act on once it does.