Your AI Feature Has a Cost of Goods. Your Pricing Page Has No Idea.
AI product gross margins average 52% against the 80-90% SaaS baseline. The gap does not close with a pricing page. It closes with metering, per-customer cost attribution and an outcome definition you can defend in a billing dispute.
Why Did Gross Margin Become an Engineering Metric?
For twenty years the software business ran on one number that made everything else work: gross margin in the mid-eighties. It paid for sales teams that lost money for eighteen months, for generous free tiers, for support organisations, for the entire apparatus of SaaS growth. It worked because the marginal cost of serving one more user of a well-built web application rounds to nothing. That assumption is what AI broke, and it broke quietly, one feature launch at a time, while the pricing page stayed exactly where it was.
The numbers are now clear enough to plan against. ICONIQ's State of AI bi-annual snapshot put the average AI product gross margin at 52% in 2026, up from 41% in 2024 and 45% in 2025. The direction is encouraging and the level is not: a 52% gross margin is a hardware business wearing a software logo. Bessemer's own read on LLM-native companies lands higher, around 65%, and the traditional SaaS benchmark that every board deck still anchors on remains 80-90%.
The mechanism is easier to feel at the level of a single seat. SaaSMag's breakdown of AI COGS compression works the arithmetic: bolt an AI assistant onto an $80 per month seat, add $15 of direct variable cost, and the gross margin on that seat falls from about 80% to about 65% without a single line of the contract changing. At company scale the same analysis puts inference at roughly 23% of revenue for scaling-stage AI B2B companies, which is to say that every $1 million of AI product revenue arrives with about $230,000 of inference cost already attached to it.
The public comparables tell a quieter version of the same story. HubSpot's gross margin drifted from 85% in mid-2024 to 84% by the first quarter of 2026. Snowflake reported 67.2% product gross margin on a trailing basis in its fourth quarter of fiscal 2026 while guiding toward 75%. Datadog held 80%. These are not catastrophes, they are the sound of a cost base changing shape underneath businesses large enough to absorb it. A Series A company shipping an agent feature does not have that cushion.
The structural point matters more than any single figure. Traditional SaaS cost of goods scales with headcount and with hosting that you provision ahead of demand. AI cost of goods scales with product usage, in the same direction and at the same moment as revenue, which means margin is no longer a property of the business model. It is a property of the code path. Whether a customer costs you $3 or $300 a month is decided by how many tokens your prompt carries, which model your router picked, whether your cache hit, and how many times your agent retried. Those are engineering decisions, and until recently nobody treated them as finance decisions too.
Key Takeaways
- Average AI product gross margin was 52% in 2026 against an 80-90% traditional SaaS benchmark
- Inference alone consumes roughly 23% of revenue at scaling-stage AI B2B companies
- A $15 variable cost on an $80 seat moves that seat's margin from about 80% to about 65%
- AI COGS scales with usage rather than headcount, so margin becomes a property of the code path
Why Per-Seat Pricing Stopped Working, and What Replaced It
Per-seat pricing was never really about seats. It was a proxy for value that happened to be cheap to measure, stable to forecast, and completely disconnected from cost of delivery. That last property was a feature when delivery cost nothing. It becomes a liability the moment one seat can generate a hundred times more cost than another seat on the same plan.
So the market moved, and it moved fast. The SaaS CFO's analysis of the shift, drawing on Deloitte and Gartner forecasts, has per-seat revenue share falling from 21% to 15% by 2030, with more than 40% of enterprise SaaS spend moving to usage, agent or outcome-based models over the same period. Hybrid models, seats plus usage, already account for roughly 46% of the market and are projected to reach 61% by the end of 2026.
In AI-native products the transition has already happened. Flexprice's June 2026 analysis of 50 AI products found that 46 of them had a usage component somewhere in the pricing, with only four holding a flat per-seat plan and no meter at all. More revealing is what those 50 products stack together: tiered pricing in 38, prepaid credit plans in 30, pay-per-use in 23, overage fees in 22 and volume tiers in 17. The typical AI pricing page is not one mechanic, it is two or three layered on top of each other.
Salesforce is the clearest illustration that nobody has settled this. Its Agentforce line has run per-conversation pricing at around $2, a per-action rate near $0.10, Flex Credits, and conventional per-user licensing at $125 per month, concurrently. That is not indecision so much as a hedge, and it is a reasonable one when the vendor does not yet know which unit its customers will accept or which one it can serve profitably.
For engineering leaders the consequence is unglamorous and specific. Every one of these mechanics is a measurement contract. Tiered plans need entitlement checks. Prepaid credits need a real-time balance that cannot go negative under concurrency. Overages need a threshold you can prove you crossed, at a timestamp a customer can audit. Outcome pricing needs a definition of the outcome that holds up when someone disputes an invoice. None of that exists in your codebase because the product was priced per seat, and per seat needed nothing more than a row in a users table.
The Cursor Lesson: You Cannot Price What You Never Instrumented
The most instructive public failure in AI pricing was not a small company. On 16 June 2025 Cursor changed the shape of its Pro plan, and the fallout became the reference case that every product team building AI features should read before writing its own pricing page.
The change itself was defensible. In the company's own account of what happened, each paid plan came with a credit pool equal to its price, unlimited use of an automatic model-selection mode, and frontier models drawing down against the pool. That is a rational structure. The problem was that users who had internalised the word unlimited discovered, sometimes within hours, that agentic long-context workflows drained a month's credit pool in an afternoon. Cursor apologised publicly and refunded unexpected charges incurred between 16 June and 4 July 2025.
It is worth being precise about what went wrong, because the popular reading, that they raised prices and got caught, misses the engineering lesson. The original plan was priced against an assumed usage distribution that turned out to be wrong at the tail. Agentic coding did not increase average consumption modestly, it created a class of user whose consumption was one or two orders of magnitude above the median. A flat price against a heavy-tailed cost distribution is a subsidy paid by the many to the few, and it holds only until the few find you.
The second lesson is about communication as an engineering artefact. Users were not angry about paying more, they were angry about not being able to see it coming. No live balance, no projection, no warning at 80% of the pool, no explanation of which action cost what. Every one of those is a feature somebody has to build, and none of them appear on a roadmap written by a team that thinks it is shipping a pricing change rather than a metering system.
The uncomfortable corollary for anyone shipping AI into an existing product: your current plan is already priced against an assumed usage distribution, and you almost certainly have not measured the real one. Most teams discover the tail through the invoice, which is the most expensive place to discover anything.
The Number Almost No Team Can Produce: Cost Per Customer
Ask an engineering organisation what a request costs and you will usually get a good answer. Ask what a customer costs and the room goes quiet. That gap is the single biggest reason AI features get priced badly, because average cost per customer is not merely imprecise, it is actively misleading when the distribution is skewed, which it always is.
The instrumentation requirement is not exotic, and it is not optional. Braintrust's playbook on tracking LLM costs puts it plainly: attribution means carrying a customer identifier, a feature identifier and a run identifier on every span, so that a token count can be rolled up along any of those axes afterwards. Finout's treatment of per-customer and per-feature AI cost makes the same point from the finance side, where the question is not cost per inference but cost to serve, and the answer has to reconcile against an actual invoice from an actual provider.
What teams find when they first build this is consistently uncomfortable. A small number of accounts consume a large share of inference spend. A feature that looked like a differentiator turns out to be the margin drain. A tier that sales loves is underwater on its heaviest third of customers while the light users subsidise them invisibly. None of this is visible in an aggregate cloud bill, and none of it is fixable by an optimisation exercise that does not know which customers to optimise for.
The second-order value is contractual rather than technical. Once cost per account is queryable, renewal conversations change character. You can price a fair-use ceiling because you know where fair use actually sits. You can offer a committed-volume discount you can defend. You can identify the accounts where the right move is a workflow change rather than a price increase, because the cost is coming from a retry loop or an over-stuffed context window rather than from genuine value delivered.
The rule of thumb that emerges is blunt: you cannot price what you cannot measure, and you cannot optimise what you cannot trace. Cost attribution is not an observability nice-to-have on the far side of product-market fit. It is the difference between having an AI product and having an AI business, and it needs to exist before the pricing page does.
Key Takeaways
- Attribution requires customer, feature and run identifiers on every traced span, not just aggregate token counts
- Average cost per customer is misleading because inference spend is heavily skewed toward a small set of accounts
- Engineering asks for cost per inference; finance needs cost to serve, reconciled against the provider invoice
- Per-account cost data changes renewal negotiations, fair-use ceilings and committed-volume discounts
Outcome Pricing Is Clean on the Pricing Page and Brutal Underneath
Outcome-based pricing is the most intellectually satisfying answer to the margin problem. Charge for the resolved ticket, the qualified lead, the completed job. Cost and revenue move together, the customer only pays for value, and the incentive alignment is close to perfect. It is also the hardest thing on this list to build, and the difficulty is entirely in the definition rather than the billing.
Look at what shipping vendors have actually committed to. Intercom's Fin charges $0.99 per billable outcome, and a detailed breakdown of that pricing shows how much definitional machinery sits behind one number: resolutions, procedure handoffs and disqualifications each bill at $0.99, lead qualifications at $9.99, escalations with no outcome are free, there is a floor of 50 outcomes a month, one outcome per conversation, and no rollover. Crucially, a resolution is recorded either when the customer confirms the help worked or when the customer simply goes quiet for 24 hours.
That last mechanic is where outcome pricing gets genuinely contested. The Pricing Conundrum's survey of what AI companies actually charge for makes the objection precisely: an inactivity window treats an abandoned, frustrated customer identically to a satisfied one, and distinguishing a happy user from a quiet defector through automated signals alone is close to impossible without expensive follow-up. The same survey catalogues the going rates elsewhere, HubSpot at $0.50 per resolved conversation and $1 per lead recommended, Zendesk at roughly $2 per resolution or $1.50 with committed volume, Salesforce Agentforce at around $2 per conversation or $0.10 per standard action. Every one of those numbers is a definition wearing a price tag.
The engineering that follows from this is real work. You need an event stream that captures the signals constituting an outcome, a deterministic rule that turns those signals into a billable event, an immutable record of why each event was classified as it was, and a customer-facing view that drills from an invoice line down to the individual conversation behind it. You need a dispute path that can reverse a charge and re-issue, and an audit trail that survives being argued with by a procurement team. Vendors in this market name attribution as the hard problem and almost none of them publish their method, which tells you how much of the value sits in the implementation.
There is a case for scepticism about the whole model, and a widely-read Forbes piece calling outcome-based pricing the most expensive myth in enterprise AI argues it transfers measurement risk to whoever is worse at measuring. The pragmatic reading is not that outcome pricing is wrong, but that its cost sits in a place most teams do not budget for. If you cannot define done in a sentence a customer's lawyer would accept and a query can evaluate, you are not ready to bill on it.
Key Takeaways
- Fin bills $0.99 per outcome across three outcome types, $9.99 for lead qualification, with a 50-outcome monthly floor
- A resolution can be recorded when a customer confirms help worked or simply goes silent for 24 hours
- Published rates elsewhere range from $0.50 per resolved conversation to $2 per resolution or conversation
- Outcome pricing needs an immutable classification record, a drill-down invoice view and a charge-reversal path
The Metering Pipeline Is a Distributed System, Not a Database Column
Once you accept that something has to be metered, you have quietly signed up to build or buy a distributed system whose correctness requirement is higher than most of your product. A dropped usage event is not a monitoring gap. It is revenue that no longer exists, and unlike a failed request nobody will ever retry it.
The leakage numbers are the argument. Lago's breakdown of SaaS revenue leakage, citing MGI Research, puts billing-related leakage at 1-5% of revenue annually, and the range is not evenly distributed: flat-rate subscriptions leak 0.5-1%, usage-based and hybrid pricing leaks 2-5%, and enterprise contracts with custom terms exceed 5%. Moving to usage-based pricing without building the pipeline to support it moves you up that scale. The same analysis names metering gaps as the largest single source for usage-based companies, with dropped events during high-throughput periods the specific failure, and notes that 42% of SaaS companies have subscriptions where the billed rate has diverged from the contracted one.
The operational picture is no better. A PwC UK and m3ter survey of 350 software vendor executives reported by The Register found 44% of UK business leaders struggling to measure consumption of usage-based software at all, 87% saying their billing systems lack integration with ERP or general ledger, and 48% with no integration between billing and CRM. The same piece puts 4-7% of annual recurring revenue at risk from inefficient billing, and notes that PwC's 2026 CEO survey found only 30% of companies reporting increased revenue from AI in the preceding twelve months. Some of that gap is capability. A meaningful part of it is an inability to convert capability into an auditable invoice.
The requirements that fall out of this are recognisable to anyone who has built event infrastructure, which is exactly why they should not be improvised by a product team under a pricing deadline. Usage events need idempotency keys, because at-least-once delivery is the only delivery you will get. Aggregation has to tolerate late and out-of-order arrivals without double-counting or silently dropping. The raw event store has to be immutable and replayable, so that a pricing bug can be corrected by recomputation rather than by a spreadsheet and an apology. Credit balances need concurrency control that holds under parallel agent runs. And the whole thing needs daily reconciliation against both the provider invoice on the cost side and the issued invoices on the revenue side, because the only way to know your meter is right is to check it against two independent sources.
The build-versus-buy answer, for most teams, is a split. Orb's framing of the decision is the useful one: the rating engine, invoicing, tax and revenue recognition are commodities with mature vendors, while the meter itself, the thing that decides what counts as a billable event in your product, is domain logic that nobody can sell you. Buy the engine, build the meter, and be honest that the meter is a product surface with its own tests, its own SLOs and its own on-call.
Key Takeaways
- Billing leakage runs 1-5% of revenue, rising to 2-5% for usage-based and hybrid models and above 5% for custom enterprise terms
- 87% of surveyed vendors have billing systems that do not integrate with ERP or general ledger
- Usage events need idempotency keys, late-arrival tolerance, an immutable replayable store and daily two-sided reconciliation
- Buy the rating and invoicing engine; the meter that defines a billable event is domain logic you have to own
The Engineering Levers That Actually Move the Margin
Measurement tells you where the money goes. Recovering it is a separate programme, and the levers are well understood by now even if they are unevenly applied.
Model routing is the largest single lever and the one most often left on the table. Sending every request to a frontier model is the equivalent of running your entire fleet on the largest instance type because it was simplest to configure. SaaSMag's COGS analysis cites Red Hat data putting compute savings from routing at up to 70%, and the mechanism is simply matching task difficulty to model capability, with an escalation path for the cases where the cheap model is not good enough. Related, deploying a fine-tuned smaller model for the high-volume, well-defined path is now a mainstream architecture rather than an experiment, a decision we have worked through in detail in the case for small language models in production.
Caching is the cheapest win available and remains under-exploited. Cached input tokens attract discounts on the order of 90% from the major providers, which means the difference between a prompt architecture that keeps a stable prefix and one that reshuffles context on every call can be most of your inference bill. Context discipline compounds it: input tokens dominate spend in agentic workloads, and every unnecessary document retrieved into a prompt is billed on every subsequent turn of that conversation.
Then there are the levers that look like quality work and pay out as margin. A weak evaluation suite produces silent regressions that surface as retries, and retries are billed at full price, which is one of the reasons the eval gap costs more than teams expect. Agent loop caps, timeouts and per-tenant budget guardrails turn an unbounded cost into a bounded one, and a graceful degradation path, serving a smaller model or a cached answer when a tenant crosses its budget, is far better than either eating the cost or hard-failing a paying customer. The internal cost-control side of this, and how to run it as a discipline rather than a quarterly panic, is covered in our piece on AI FinOps and the invoice nobody budgeted for.
The sequencing matters more than the individual techniques. Instrument attribution first, because every lever above needs a before-and-after number attached to a customer and a feature to be worth pulling. Teams that optimise before they measure reliably spend three weeks shaving 15% off a code path that accounted for 2% of the bill, while the actual drain sits in a retrieval step nobody looked at.
Why This Work Falls Between Four Teams, and Who Should Own It
There is a structural reason AI unit economics stays broken in otherwise competent organisations, and it is not technical difficulty. It is ownership. The work spans product, which owns the pricing page; finance, which owns the P&L and the revenue recognition rules; platform engineering, which owns the inference path and the telemetry; and data, which owns the aggregation and the reporting. Every one of those functions can describe the problem. None of them can fix it alone, and the piece that falls between them, a metering and attribution layer with its own tests and its own on-call, is nobody's quarterly objective.
The result is a predictable pattern. The pricing change ships on a marketing timeline. The meter is assembled in six weeks by whoever had capacity, usually as a stored procedure over an events table with no idempotency and no reconciliation. It works until the first month with real volume, and then finance finds a discrepancy nobody can explain, engineering discovers that the raw events were aggregated destructively and cannot be recomputed, and a customer disputes an invoice the team has no way to substantiate.
This is exactly the shape of work a dedicated development team handles better than either an internal squad borrowing time between roadmap commitments or a project agency delivering to a fixed scope. It is not a two-month project. It is a system with a long tail of correctness work, reconciliation jobs, dispute tooling, pricing migrations and new meters for each feature that ships afterwards. It needs people who will still be there in month twelve to answer questions about a classification rule they wrote in month two.
It also needs to sit close to your finance and product conversations, which is the practical argument for nearshore development over a distant offshore arrangement on this particular class of work. A meter definition is negotiated, not specified. It takes a live conversation between someone who understands the revenue recognition constraint and someone who understands what the event stream can actually prove, and that conversation does not survive being reduced to a ticket and a nine-hour turnaround. Our teams in Serbia work a full business day overlapping European hours and most of the US morning, which is the difference between resolving an outcome-definition question in an afternoon and resolving it next sprint.
For teams that have the platform capability but not the headcount, staff augmentation into an existing squad is usually the faster route, since the domain knowledge about what constitutes a billable outcome in your product is already in the building and does not transfer well. For teams building the AI capability itself alongside the economics that make it viable, our AI automation and engineering practice treats attribution and cost guardrails as part of the initial build rather than a retrofit, because retrofitting attribution into a system that was never designed to carry a customer identifier through its call graph is substantially more expensive than putting it there on day one.
Price the Product You Actually Run
The industry spent two decades building intuitions on 85% gross margins and is now shipping products that run at 52%, using a pricing model designed for a cost structure that no longer exists. The correction is under way, 46 of 50 AI products now meter something, per-seat revenue share is forecast to fall by nearly a third by 2030, and outcome pricing has moved from conference talk to published rate cards at $0.99 a resolution. What has not moved at the same pace is the engineering that makes any of it work. A price is a claim about cost, and a claim about cost you cannot substantiate from your own telemetry is a guess with an invoice attached to it. The teams getting this right did the unglamorous thing first: they put a customer identifier on every span, wrote down what an outcome is in language a procurement lawyer would sign, built a meter with idempotency and replay, and reconciled it daily against two independent sources. Then they changed the pricing page, and they changed it knowing which customers would move from profitable to underwater and by how much. That work does not fit neatly inside product, finance, platform or data, which is precisely why it keeps not happening, and precisely why it is worth giving to a team whose job it actually is.
Building a team in Eastern Europe?
StepTo helps European and US companies build senior-led nearshore engineering teams in Serbia. Let's talk about what your next engagement could look like.
Start a conversationWritten by
Igor GazivodaCo-founder & CEO · StepTo
Igor has 15+ years in software engineering and business development. Former CTO at a Series A fintech startup, he specializes in scaling engineering teams, nearshore strategy, and AI-driven product development. He holds a Master's in Computer Science from the University of Belgrade and has published on distributed systems architecture.
LinkedIn →