The deck reads well, the bill doesn't
Most diligence on an AI company still moves through the same three steps: read the deck, watch the demo, run a handful of reference calls, treating the product as the artifact worth inspecting. That approach was built for a software era where the marginal cost of serving one more user rounded to zero, so unit economics could be inferred from growth alone without much scrutiny. It fails here because the product being sold carries a metered cost inside every single response it generates, and that cost does not disappear once the funding round closes and the growth story takes over from the story about margin.
A demo shows what the model can do under ideal conditions: short prompts, cached context, a curated set of test cases chosen because they work well on camera. It says almost nothing about what happens once the same product is asked to hold a long conversation, retrieve from a growing knowledge base, or run several model calls per user action, which is the ordinary shape of real usage rather than the exception investors are shown. The gap between the demo's cost and the product's real cost, at real usage, is the gap most diligence never actually measures.
The number that actually predicts survival
The single figure that predicts whether an AI company survives past its first eighteen months is not revenue growth or logo count. It is marginal inference cost per active user, tracked against the price that user pays, and watched as usage climbs rather than measured once as a snapshot. A team can look profitable at low usage and lose money on every heavy user, which is precisely the moment investors expect the story to improve rather than quietly invert, a mismatch this pricing piece covers in full. That inversion tends to arrive right when the company can least afford to be surprised by it.
A company can look profitable at low usage and lose money on every user who actually loves the product.
This number is hard to get cleanly because most founders have not separated the fixed cost of infrastructure from the variable cost that moves with usage, so the blended figure they report hides the trend underneath it. Asking for the marginal cost directly, and asking how it has moved over the last two quarters of usage growth, tells a diligence team more about the model's real relationship between growth and margin than any slide in the deck. A team that cannot answer this question has usually not asked it of themselves either, which is the same blind spot behind assuming a scaling curve the product hasn't earned.
Usage scaling breaks the model quietly
The failure mode is rarely dramatic. A product that looks like healthy expansion, users spending more time in the app, running more queries, generating longer sessions, is often accumulating cost faster than revenue in a way that shows up nowhere on a slide until the burn rate does. Growth and margin compression can be the same event, described from two different vantage points, and a team that only tracks the growth vantage point will not see the margin one coming until it has already arrived and reshaped the runway before anyone flagged it in the numbers.
This gets worse in categories where value is tied to context length or retrieval depth, because the cost curve is not linear with usage, it accelerates. A support tool that ingests a growing ticket history, a research assistant that holds a widening context window, a workflow agent that chains several model calls per task: each gets more expensive per interaction as it gets more useful, which is the opposite of what a normal software cost curve does, and the opposite of what most financial models built for software assume by default. Few teams price for that curve before it bites.
What diligence should actually price
A diligence process built for this reality asks for the cost per interaction at three different usage tiers, not one blended average, and asks how the founding team plans to hold margin as the heaviest users grow heavier still. It asks whether pricing is metered to usage or flat, and if flat, how long the team can absorb the mismatch before its heaviest customers become structurally unprofitable. None of this shows up in a pitch deck built to tell a growth story, because a growth story and a margin story pull in opposite directions once the underlying cost is metered.
None of this requires exotic modeling. It requires pulling the actual inference or compute bill, mapping it against actual active users over the same period, and asking the founder to explain the trend line rather than the total. A team that can produce this cleanly, and that has already adjusted pricing or architecture in response to what it found, is telling a diligence team something a demo cannot: that they know what their product costs to run, not just what it is capable of doing in front of investors on a good day.
The deeper problem this piece is really about is not model economics, it is what diligence has quietly optimized for. Software-era diligence was built to catch story problems: is there a market, does the team execute, does the demo actually work. It was never built to catch a cost structure that moves in the opposite direction from growth, because that structure did not used to exist. Pricing the model bill instead of the pitch is not a new step bolted onto the old process, it is the recognition that the old process was built to diagnose a different kind of company than the one now asking for money.
