👋 Hey, Sahil here - welcome to today’s edition of Venture Curator, where we break down how great startups grow, how top investors think, and what’s shaping the future of tech.
P.S. Get access to 100+ startup & VC resources, investor databases, fundraising templates, 150+ premium archive posts and exclusive startup research - all in one place.
FROM OUR PARTNER - KAPITALWISE
💹 Your financial goals are personal. Your advisor should be too.
Not every financial advisor is right for every investor. The right fit depends on what you’re building toward, the kind of guidance you need, and where you are financially.
Kapitalwise AdvisorConnect uses AI-powered matching to connect you with vetted financial advisors and planners based on your needs - making it easier to find relevant expertise without spending hours searching and comparing.
Think of it as a smarter starting point for an important financial decision: fewer random options, more relevant matches.
Partnership With Us
Get your product in front of over 125,000+ audience - Our newsletter is read by thousands of tech professionals, founders, investors and managers worldwide. Get in touch today.
📜 DEEP DIVE
Why are so many AI startups calculating ARR wrong?
Take current MRR, multiply by 12, put it on the slide. You’ve done this. Every founder has. It’s the fastest way to turn a month of revenue into a growth story, and for a decade it was close enough to true that nobody argued with it.
It stops being true the moment any part of your revenue is usage-based. And if you’re building anything AI-adjacent in 2026, some part of it almost certainly is.
Quick definition, because this matters for everything below:
Usage-based pricing (also called consumption pricing) means customers pay based on what they actually use - API calls, tokens, compute, seats-plus-overage - instead of a flat fee that’s identical every month.
It’s now the pricing model for 38% of SaaS companies, and it’s close to the default for AI products, where cost genuinely does scale with usage in a way a flat subscription can’t absorb.
Usage-based pricing is good for you. It’s also the exact thing that breaks the math you’re probably still using to report growth.
Where the math actually breaks
MRR × 12 assumes one thing: that this month looks like next month, and the month after that.
For seat-based software, that’s roughly true - nobody doubles their headcount overnight.
For usage, it’s rarely true.
A customer runs a big batch job. A retailer has a seasonal spike. A client onboards three new teams in one week and then plateaus. None of that is “recurring” in the way the word implies, but the moment it lands in a given month, your naive ARR calculation happily multiplies it by 12 and reports it as your steady-state business.
One infrastructure-metering vendor that works with usage-heavy companies put it plainly: presenting a single ARR number to your board means you’re claiming every dollar behaves like a predictable subscription. That assumption breaks the moment your largest customer throttles back consumption, and your “recurring” revenue drops with it.
Here’s what that actually looks like on a chart - This is a simplified model of a usage-based startup with one customer usage burst in November - not an unusual pattern for anyone selling API or compute-metered products with lumpy enterprise usage:
Naive ARR - this month’s revenue × 12. Reacts to spikes, so it’s often wrong.
Smoothed run-rate - 3-month average × 12. Evens out spikes, closer to the truth.
Committed baseline ARR - only what’s guaranteed by contract. No usage, no spikes - the safest number.
The naive number (current month × 12) swings from $850K to $1.18M to $890K across three months. Nothing about the underlying business changed that fast. What changed was one customer’s usage in one month, multiplied by twelve and mistaken for a trend.
A separate framework for comparing the two metrics head-on makes the gap concrete: in a worked example where a company collects $450K in a month - $300K from actual subscription contracts, the rest from uncommitted usage overage and a one-time project - the contracted ARR comes out to $3.6M. Annualising the full month instead gives you $5.4M.
That’s a 50% gap between the two numbers, and it comes entirely from treating a one-off month as if it were guaranteed to repeat.
Why this is a you-problem, not just an investor-problem
Most of what’s been written about ARR inflation this year focuses on founders misleading investors. That’s real, but it’s the smaller risk for most of you.
The bigger one: you’re using this same broken number to run your own company.
Runway math, hiring plans, burn multiples - all of it gets built against whatever number sits in the ARR cell of your model. If that number is inflated by a single spike month, you’ll greenlight a hire you can’t actually support, or tell your board you have more runway than you do, without anyone lying to anyone. You did it to yourself, using a formula that was never built for how you get paid.
Two terms worth being precise about, since they get used interchangeably and shouldn’t be:
Baseline (or committed) ARR - revenue from customers with an actual minimum commitment: a contracted floor, a subscription fee, something that doesn’t depend on behaviour changing next month.
Variable (or usage) run-rate - everything above that floor: overage, consumption spikes, anything tied to how much a customer happened to do this month.
Blending these into one “ARR” line is the single most common way founders make their own numbers less useful to themselves.
Who this actually hits hardest
Not every business model is exposed equally. Before you check your own numbers, place yourself on this spectrum: