Capstone: AI Features in a SaaS Product

Most engineers will meet AI design not as a new product but as a feature added to an existing one: a project management tool that wants to summarize threads, a help desk that wants to draft replies, a CRM that wants to search by meaning. The design problem changes. The question is no longer "can we build it" but "should we, where, at what cost, and how do we ship it safely to customers who already trust us."

Building a new house is one thing. Adding a room to a house where people already live means working around their furniture: you cannot cut the power for a week, you must not damage what is there, and the new room has to fit the existing structure and the budget. AI features in a SaaS product are additions to an occupied house.

• -Start where the work is repetitive text: summarize a long thread, draft a reply, extract fields from a document, search by meaning. A model gives a good first draft and a person finishes it.
• -Prefer features where a wrong answer is cheap and easy to spot, and where the user stays in control: suggestions, not automatic actions.
• -Delay features where a wrong answer is costly or invisible, such as sending messages or changing records on its own, until you have evals and approval steps.
• -Ask for each candidate: how often is it used, how much time does it save, how bad is a miss, and what does it cost per use?

A seat that costs $20 a month cannot afford unlimited use of a costly feature. Usage is also uneven: most people use an AI feature a little, and a few use it all day. The code simulates 5,000 seats at $20 a month, where each AI request costs $0.05 in model fees, with a spread of usage in which a few people use it far more than the typical seat. It compares unlimited use with two fair-use caps. The figures are invented. Press Run and read the margin column.

With unlimited use, the model bill is $39,308 a month, $7.86 per seat, leaving a gross margin of 61% on this feature alone. The heaviest 5% of seats make 32% of all requests, while the median seat sends only 79. A cap of 300 requests a month cuts the bill to $28,635 and lifts the margin to 71%. A cap of 150 brings it to $21,324 and 79%. Most customers never notice the cap, since the typical seat is far below it. The business decision is where to set it, whether to sell a higher tier for heavy users, and whether to meter usage.

• -Shadow mode: run the feature on real data without showing results, and compare with what humans did.
• -Internal dogfooding, then a small opt-in beta with a feedback button on every output.
• -A canary by customer or by percentage, with guardrail metrics for errors, latency, complaints, and cost per active user.
• -General availability, behind a feature flag per workspace so a customer can turn it off, and you can roll back in minutes.

• -Tenant isolation: one customer's data must never appear in another's output, in prompts, caches, logs, or indexes. Enforce it in retrieval and storage, not only in the prompt.
• -Show sources and let users edit before anything is sent. Make undo easy.
• -Data terms: check what your model provider does with customer data, and what your own contracts promise. Offer an option to turn the feature off for sensitive customers.
• -Evals on your own data: build an eval set from real, consented examples, and run it on every prompt or model change.
• -Cost guardrails: per-workspace budgets, rate limits, and alerts, so a loop or an abusive account cannot run up the bill.

• -Adoption: the share of active users who try the feature and come back.
• -Quality: the rate at which suggestions are accepted, how much users edit them, and thumbs up or down.
• -Value: time saved, and whether retention or upgrades rise for users of the feature.
• -Cost: dollars per active user and per request, as percentiles.