A SaaS company added an AI summarization feature and priced it at $49 a month as an add-on.
The number came from looking at what competitors charged, not from what the feature cost to run. Six months later, a subset of power users running the feature dozens of times a day were costing more in model API calls than the add-on brought in, and the finance team only found out when someone finally split the infrastructure line apart to see what was in it.
The cost usually ends up in the wrong bucket
A lot of AI feature costs get filed under R&D or general infrastructure instead of cost of goods sold, which hides the problem from the one report that would catch it. If a feature’s cost lives in an engineering budget, gross margin looks fine because the cost never touches revenue in the P&L. The AI feature might be losing money on every heavy user and nobody would know from looking at the margin line, because the margin line was never asked to include it. Any cost that scales with usage and exists because a customer is using the product belongs in COGS, whether it’s a server, a support ticket, or a call to a language model.
Average cost hides what heavy users cost
Founders often calculate a rough cost per customer by dividing total model spend by total customers, which produces a number that looks manageable. That average buries the fact that AI usage is rarely even. A small group of power users can generate a large share of total inference cost, and if the product is priced flat regardless of usage, those customers are quietly unprofitable while the average customer looks fine. A model needs to separate cost by usage tier, not just by customer count, or it will keep reporting healthy margin right up until the day the numbers stop matching the bank balance.
Model pricing and model versions both move without warning
Traditional infrastructure costs are stable enough to forecast a year out. AI infrastructure costs are not. A model provider can change per-token pricing, and a product team can upgrade to a more capable, more expensive model version to keep up with a competitor’s feature. Either change flows straight into cost per customer without touching the price a customer pays. A margin forecast built on a snapshot of today’s pricing is already out of date the day a provider adjusts a rate card, and the founders who get caught off guard are usually the ones who never built a line for this kind of change into the model in the first place.
What a workable model tracks
Getting this right doesn’t require anything exotic. It means tracking inference cost per customer or per account, broken out by usage tier so the heaviest users are visible rather than averaged away. It means treating that cost as COGS in the model, not R&D, so gross margin reflects what a feature costs to run in real terms. And it means revisiting the assumption every quarter instead of setting it once at launch, since both usage patterns and provider pricing shift faster than a typical SaaS cost structure ever did.
Most AI features are good bets that were priced without the full picture. The founders getting this right are pricing usage-heavy AI features closer to how a utility prices electricity, with the cost of serving a heavy user built into what that user pays, instead of pricing everyone the same and hoping usage stays average.