Do the classic SaaS metrics still work if we are an AI native company?
Partly, and the parts that break matter. ARR assumes a stable recurring subscription, but usage priced AI revenue swings with consumption, so a single ARR figure hides a lot. Gross margin, which SaaS people barely thought about because it was always around eighty percent, becomes a first order metric once inference costs scale with usage. And LTV to CAC gets shaky when both churn and expansion are far more volatile than in seat based software. What still holds: CAC payback, net revenue retention, and the discipline of measuring cohorts rather than aggregates. The practical move is to report ARR alongside gross margin and consumption growth rather than on its own, and to say explicitly which revenue is contracted and which is consumption based.
Go deeper
4 resources, 4 link-checked.
📰 Newsletter
✓ Link checkedPaidAdvanced
Names precisely which classic metrics stop working when revenue is consumption based and inference costs eat gross margin, then proposes replacements. The free preview alone reframes the problem.
Poyar's argument: ARR is becoming untrustworthy for AI-native companies, and DAU/MAU break when the product runs as digital labour or inside another product via MCP.
He does not trust LTV for any AI product right now, given experimentation budgets and the shipping pace of Anthropic and OpenAI.
Mixed monetisation splits revenue into high-margin platform and low-margin tokens, so a single gross margin line hides the business.
Survey data from over eight hundred private companies, with an efficient growth matrix that plots CAC payback against NRR so you can locate yourself rather than just read averages.
The annual dataset on the hundred best private cloud companies, including growth rates, multiples, and how long it now takes to reach a hundred million dollars ARR. This is the definition of best in class, with numbers attached.
This question is about which classic metrics break when revenue swings with consumption, and this is a short, concrete fix for one of them: how to compute payback when there is no stable subscription number to divide by.