Blog

Why AI-native apps need a new financial framework. And a new metric to run it.

The Two-Dimensional World We Built Mobile On

For most of the last decade, the financial architecture of a mobile app or gaming studio rested on two numbers: Customer Acquisition Cost (CAC) and Lifetime Value (LTV). Get the ratio above 1x and in theory the business works. It was elegant precisely because it was simple.

Underpinning that elegance was a structural reality that founders, UA teams and CFOs understood intuitively: the marginal cost of an additional user was close to zero. Incremental infrastructure (think server allocation, bandwidth, CDN fees) was real but trivial, sensibly treated as a near-fixed cost pooled across the user base. The unit economics were essentially two-dimensional: spend to acquire, earn from the cohort, watch the payback window close.

That model is now structurally incomplete for a growing class of applications.

When Engagement Stops Being Free

AI-native apps – products where artificial intelligence is the core proposition, not just a feature, break the near-zero marginal cost assumption fundamentally. Think companion apps, AI tutors, personalised coaching tools, or conversational game characters, where every interaction consumes compute. Every prompt and generated response carries a token cost directly attributable to that user, in that session, at that moment. This is no longer infrastructure overhead to be pooled and amortised, but a true Cost of Goods Sold (COGS) that scales directly with how intensively each user engages with the product.

The causal chain is worth stating precisely. Better retention drives higher engagement. Higher engagement drives more active usage. More active usage generates more compute cost. This is a usage-driven COGS caused not by retention itself, but by the behaviour that retention enables.

This is the real structural change versus traditional mobile. High engagement was previously unambiguously good. More sessions meant more revenue at essentially no additional direct cost. In an AI-native app, high engagement is still good as an LTV driver, but it is now also a driver of direct cost. Engagement and cost are no longer decoupled.

This means two cohorts with identical CAC and similar revenue profiles can have materially different economics if their usage behaviour diverges. A deeply engaged cohort carries a fundamentally different cost structure than one that uses AI features occasionally, even if top-line revenue looks the same. Behaviour inside the product is now a first-class variable in unit economics and no longer just an operational footnote.

Introducing the Third Dimension: Compute Cost of Retention (CCR)

We need to elevate this usage-driven COGS to a first-class variable in the unit economics framework. We call it the Compute Cost of Retention, or CCR — the aggregate compute cost directly attributable to a user over their retained lifetime, driven entirely by how actively they use the product.

At its simplest:

CCR = Average Daily Tokens × Cost Per Token × Expected Retention Days

This is a useful heuristic, but CCR should be modeled over time by cohort as usage intensity is not static. Early users often engage most heavily as they explore the product; usage then typically stabilises. The CCR curve is a function of actual behavioural data, not a flat extrapolation.

CCR now sits alongside CAC and LTV as the third axis of a three-dimensional unit economics framework:

• CAC — what you spend to acquire the user
• LTV — what you earn from the user over their lifetime
• CCR — what it costs you in direct COGS to deliver the product to that user over their lifetime

The question shifts from “how much in, how much out” to “how much in, how much out, and how much does it cost to keep the promise.”

The ROAS Reckoning: How CCR Pushes Out Payback Periods

This is where CCR has its most immediate and damaging practical effect. ROAS payback — the point at which cumulative cohort revenue covers acquisition cost — is how studios manage cash, size debt facilities, and make channel allocation decisions. In an AI-native context, ignoring CCR causes it to materially overstate economic attractiveness and understate how long payback actually takes.

Here is the mechanism. In most app cohorts, gross revenue recovery is front-loaded — the steepest part of the cumulative revenue curve comes early, when newly acquired users are most active. Compute cost follows the same shape: early usage is highest, generating the most token consumption in the first months of a user’s life. The result is that early cohort revenue which would otherwise close the CAC payback gap is instead partially absorbed by compute cost. CCR does not change the revenue curve but rather it reduces how efficiently early revenue converts into actual payback, pushing payback windows further out.

The effect can be severe. A founder I spoke with recently described pushing his ROAS breakeven from six months to fifteen months once CCR was properly modeled. This is clearly not a rounding error, but the difference between a business that can be financed on conventional terms and one that requires a fundamentally different financing approach.

The right analytical distinction is between gross ROAS (cumulative revenue against CAC) and net cohort recovery (cumulative revenue minus compute cost against CAC). It is the second curve, not the first, that represents true economic payback. Studios reporting only gross ROAS are flying partially blind.

On compute cost trends: token prices are falling, but building UA strategy on an assumed cost curve is a macro bet, not a financial plan. There is also an important counterforce which is that better models drive higher engagement and more tokens consumed per user per day, potentially offsetting per-token price declines. Model a range of scenarios. Do not anchor to a single cost assumption.

NARPDAU: CCR Made Visible Daily

For daily operational reporting, I propose NARPDAU, or Net Average Revenue Per Daily Active User:

NARPDAU = ARPDAU − Daily Compute Cost Per Active User

CCR is the cohort-level framework concept. NARPDAU is the dashboard metric calculated daily that makes it visible in real time. It surfaces daily margin compression from compute, and crucially exposes intraweek dynamics that monthly models miss. In habit-forming AI apps, usage normally spikes at weekends. A studio tracking ARPDAU on Monday morning might feel comfortable. Tracking NARPDAU, they would see the weekend compression in real contribution margin and respond accordingly.

Beyond Breakeven: Debt, M&A and the Long Tail

CCR does not stop accruing at ROAS breakeven. For studios carrying debt, ongoing compute costs affect the operating cash generation that services facilities, with direct implications for covenant headroom and interest cover. Lenders not yet asking for CCR modelling in credit submissions should be.

In M&A, a studio with strong retention and high DAU looks attractive on conventional multiples, but if that engagement is being delivered at substantial compute cost, the true margin profile is materially different from what headline numbers suggest. Acquirers will increasingly treat AI cost architecture as a diligence item. Conversely, a studio that has genuinely optimised CCR efficiency — through model selection, prompt engineering, caching, and usage tiering has a structural cost advantage that is invisible in top-line metrics and represents a real competitive moat.

What Good Looks Like

• CCR is a named line item in cohort economics (not an overhead allocation)
• Modelled per user segment; heavy and light users carry materially different CCR profiles
• Stress-tested across at least three compute cost scenarios
• Net cohort recovery replaces gross ROAS as the primary payback metric
• NARPDAU sits alongside ARPDAU on the daily dashboard, with weekend and weekday cuts as standard
• UA payback window calculations incorporate CCR from day one. Gross ROAS alone will systematically over-invest in high-engagement cohorts whose true contribution margin is understated

Closing: The Third Number

The CAC/LTV framework is far from obsolete of course. But for AI-native apps it is now incomplete unless compute is treated as a part of the direct unit economics. The studios that internalise CCR will make better capital allocation decisions, access financing on better terms, and build more durable businesses.

The core insight is simple, even if the modelling is not: in AI-native apps, compute cost does not just lower margins. It reduces how much of early cohort revenue actually contributes to payback and it pushes breakeven windows out in ways that can fundamentally change the financing and operational reality of the business. The founders and CFOs who model that honestly will have a structural advantage over those who don’t.

Apply To Join