Traditional SaaS unit economics assume cost of goods sold is small and roughly fixed per customer -- a database row, a bit of storage. AI products break that assumption: every inference call has a real, usage-scaling compute cost, and it shows up directly in gross margin as revenue grows, not just in a separate infrastructure budget line.
The two cost types that matter
- Fixed burn -- team, tooling, office -- does not move with usage in the short term.
- Compute cost (COGS) -- inference and, if you train your own models, training compute -- scales with how much customers actually use the product, which usually scales with revenue.
💡 Key idea: a startup can look healthy on revenue growth alone while its compute-cost percentage quietly caps how profitable it can ever become at scale.
Why net growth (not gross growth) is the number that matters
Monthly MRR growth needs to be read net of churn. An 8% headline growth rate against 3% monthly churn nets to roughly 5% real expansion; the same 8% against 8% churn nets to roughly zero. Quoting gross growth alone, without churn context, can make a treadmill look like progress.
Reading a runway chart
Plot cash balance forward from today's position, net of fixed burn plus compute cost minus revenue, each month. The month it crosses back to zero from below (if it does) is cash-flow breakeven; the month it crosses zero from above, if fixed and compute costs together outpace growth, is when you run out of money. A shallow, late-crossing curve doesn't have one cause -- it could be growth too slow, churn too high, compute cost eating margin, or fixed burn simply too high for current revenue, and these look similar until the calculation is broken into its parts.
Practical implications
- Price with your actual compute cost per customer in mind, not just competitor pricing -- a heavy-usage customer segment can be unprofitable at a price that looks fine on average.
- Track compute cost as a percentage of revenue over time, not just in absolute dollars -- the percentage is what determines whether growth improves or erodes margin.
- Model runway with compute cost scaling explicitly, not folded into a single blended "burn rate" -- the two cost types respond differently to growth and to model-efficiency improvements.
- Revisit unit economics whenever usage patterns shift meaningfully, since heavier average usage per customer changes the compute-cost percentage even at flat pricing.
🧪 Try it yourself: the AI Startup Runway Lab simulation lets you experiment with everything described above directly in your browser.