How to add AI features to an existing SaaS without burning your runway

Adding AI to an existing SaaS looks simple on a slide deck and rarely is in the bank statement. The team has helped enough bootstrapped founders ship AI features to recognise the shape of the mistake: a well-intentioned launch, a week of enthusiastic usage, and a surprise invoice that eats a month of MRR. Large enterprises can eat that cost while they figure it out. Bootstrapped and early-stage teams cannot. This is the playbook the team uses when an AI feature has to earn its token budget from day one — how to pick the first feature, how to tier-gate it, how to cap spend, and how to design for the failure modes that will happen.

Pick a feature that pays for itself

The first AI feature in an existing SaaS should not be the flashiest one — it should be the one with the clearest line from usage to retained or upgraded revenue. The team's rule of thumb is: if you can't explain in one sentence why a user would pay more (or churn less) because of this feature, don't ship it first.

• Good first features automate an existing manual step the user already does every session — writing, summarising, classifying, extracting, drafting.
• Bad first features create new work the user didn't ask for — suggestions they have to evaluate, explanations they didn't request, chat widgets nobody opens.
• The best first features are narrow, bounded, and measurably faster than the manual alternative. 'Generate a blog post' is vague; 'draft a reply to this support ticket' is bounded.

A simple decision matrix

Tier-gate from the first commit

Every AI feature the team ships lands behind a tier gate on day one — even if the initial launch gives it to everyone. Retrofitting a gate to an existing feature is hard; users who have been using something free for a month will churn when you take it away. Shipping the gate on day one and starting with it fully open is trivial.

1. Model the AI feature as a metered entitlement from the start — 'messages per month', 'documents processed', 'tokens used'. Pick a unit your users understand.
2. Default free-tier limits that cover genuine trial usage and nothing more. The team's starting heuristic: enough to experience the feature twice, not enough to run a business on it.
3. Put the entitlement in the same billing primitive as your other usage meters. Don't build a parallel system.
4. Show remaining usage in the product UI. Users who can see the meter tick down upgrade; users who run out without warning churn.

Set a hard token budget per user

A tier gate limits feature usage — a token budget limits spend. You need both. The difference matters because a single expensive user (uploading a 2MB document to summarize, or running 40 regenerations in a row) can cost more in tokens than their entire monthly subscription. The team has seen this happen. It is not rare.

Wrap every LLM call in a cost-capped helper that checks a rolling token ledger before the call and refuses the call when the user is over budget. Fail with a friendly message that tells the user their options; do not silently degrade or, worse, eat the cost.

// A minimal cost-capped wrapper for a per-user monthly budget
type BudgetError = { code: "BUDGET_EXCEEDED"; remaining: 0; resetsAt: Date };

async function callWithBudget(opts: {
  userId: string;
  model: "sonnet-4-6" | "haiku-4-5";
  systemPrompt: string;
  userPrompt: string;
  maxInputTokens: number;
  maxOutputTokens: number;
}): Promise<{ text: string } | BudgetError> {
  const rate = PRICING[opts.model]; // { input: $/1M, output: $/1M }
  const estCostCents =
    ((opts.maxInputTokens * rate.input) / 1_000_000 +
      (opts.maxOutputTokens * rate.output) / 1_000_000) *
    100;

  const ledger = await getMonthlyLedger(opts.userId);
  if (ledger.spentCents + estCostCents > ledger.capCents) {
    return { code: "BUDGET_EXCEEDED", remaining: 0, resetsAt: ledger.resetsAt };
  }

  const resp = await anthropic.messages.create({
    model: opts.model,
    max_tokens: opts.maxOutputTokens,
    system: opts.systemPrompt,
    messages: [{ role: "user", content: opts.userPrompt }],
  });

  // Record actual, not estimated, usage
  await recordUsage(opts.userId, {
    inputTokens: resp.usage.input_tokens,
    outputTokens: resp.usage.output_tokens,
    model: opts.model,
  });

  return { text: resp.content[0].type === "text" ? resp.content[0].text : "" };
}

Route aggressively to cheaper models

In 2026, the price delta between the cheapest and most expensive frontier models on a typical RAG or classification task is roughly 20x. Claude Haiku 4.5 runs at $0.25/$1.25 per million tokens; Claude Opus 4.7 runs at $5/$25. GPT-5 Nano and Gemini 3 Flash-Lite sit at similar floors. Sending every request to the flagship model is a choice, not a default — and usually the wrong choice for bootstrapped economics.

• Classification, intent detection, routing — Haiku, GPT-5 Nano, Gemini 3 Flash-Lite. The quality difference on these tasks is usually indistinguishable.
• Short grounded answers over retrieved context — Sonnet, GPT-5, Gemini 3 Pro. Mid-tier models are the workhorse here.
• Complex multi-tool reasoning, long-context synthesis, agentic workflows — Opus, GPT-5 Pro. Reserve the premium tier for tasks that actually need it.

A simple two-model router (cheap model handles 80% of calls, premium model handles the 20% the cheap model escalates) typically cuts spend 60–75% with no noticeable drop in user-visible quality. The team has yet to see this pattern fail on a well-instrumented product.

Monitor cost per user, not just total spend

Total API spend is a lagging indicator. By the time it spikes, a feature has already been losing money for days. Cost per active user (per day and per month) is the metric the team watches instead — it surfaces pricing-model mismatches before they compound.

• Log every LLM call with user ID, model, input tokens, output tokens, cache hit flag, and feature name. This is 20 lines of middleware and a week's best investment.
• Roll up daily cost per active user per feature. Plot it against that user's subscription price. Any user whose AI cost exceeds, say, 30% of their monthly revenue is a flag — and five such users are a policy change.
• Alert on p95 cost per user, not just mean. The mean hides the expensive outliers that actually kill margins.

Design for the failure modes

LLM calls fail. Rate limits bite. Models go down. Outputs hallucinate. A production AI feature has to degrade gracefully through all of these, and the UX for degradation is a product decision that has to be made before launch, not after the first outage.

• Timeouts — every call has one. Default to 30 seconds for interactive features, 120 seconds for background jobs. Surface the timeout as a retry-able error, not a spinner that never ends.
• Rate limit and 5xx — retry with exponential backoff up to three times, then fail to a human-readable error. Never silently swallow.
• Budget exceeded — show the user their usage, their cap, and the upgrade path. Make this copy as clean as your checkout flow; it is your checkout flow.
• Hallucination — if the feature involves grounded answers, show citations and a 'this may be wrong' note for uncertain outputs. Ground truth in the source, not the model.
• Vendor outage — have a fallback model wired in behind a feature flag for critical paths. 'The AI is down' is acceptable for a nice-to-have, not for a feature users paid for.

Key takeaways

• The first AI feature should automate a step users already do — not introduce new work they didn't ask for.
• Tier-gate from day one, even if the initial limits are generous. Retrofitting limits is the hardest billing change a SaaS can make.
• Cap spend per user in code, not just in the pricing page. One unchecked power user can cost more than a hundred paying ones.
• Route to the cheapest model that meets the quality bar. A two-model router typically cuts LLM spend 60–75% without noticeable UX impact.
• Watch cost per active user, not just total spend. The expensive outliers are invisible in the mean and decisive in the p95.
• Design the failure-mode UX before launch. Timeouts, budget exceptions, and model errors are features, not afterthoughts.