Inflated AI ARR and Honest Revenue as a Micro SaaS Dev

This morning's research log surfaced TechCrunch's "How VCs and founders use inflated 'ARR' to crown AI startups." AI startups are publishing numbers that fold in contracts not yet signed or paid for, and calling those numbers plain ARR. VCs go along with it knowingly, and across the industry an inflated growth figure has become the normal operating state. Reading it, even though the scale and the digits are nothing alike, I felt this is contiguous with my own world of running a micro SaaS.

The line between ARR and CARR is being dissolved on purpose

The core of the piece is that the boundary between two numbers — ARR and CARR — is deliberately blurred. ARR is confirmed annual recurring revenue: the portion that is actually being billed right now. CARR includes contracted-but-not-yet-started, not-yet-invoiced expectations, so by definition it is larger than ARR. What the article points out is the pattern where many AI startups compute the higher CARR figure and then announce it under the label "ARR."

What's unsettling is that this isn't an outright lie. "We have the contracts" is true; they've just shifted the label up one notch. So no one gets sued, and VCs don't stop it because a bigger number is more useful in the next round. The incentive to dissolve the line works on both the side issuing the number and the side receiving it. I think this same temptation exists, in a different shape, in a solo dev's MRR reporting too. Users still in a free trial; annual contracts not divided down to a monthly figure; subscriptions that have given cancellation notice but are still being charged. Depending on what you add and what you subtract, the same business's number can swing by something like 1.5x without anyone blinking.

Solo, both the temptation to inflate and the cost of inflating are small

Startups inflate numbers for the next funding round. A solo dev has no VC, so there's no one to inflate for — is what I'd like to say, but it turned out not to be true. The exact same temptation arrives the moment you write "hit $X MRR with a micro SaaS" on X, or the moment you compress your traction into a single line for Show HN. You want to leave a strong impression on the reader, so you find yourself reaching for whichever number looks biggest.

Doing it solo has a saving grace, though: when someone asks you to break the number down, you get caught instantly. A startup's ARR sits behind an audit wall and can't be re-derived from the outside, but the numbers a solo dev publishes are small enough that if someone asks "is that MRR dividing annual plans monthly? are free periods excluded?" there's nowhere to hide. That's exactly why, for one person, being honest is the lowest-cost strategy. I feel this especially as someone running multiple micro SaaS products solo. A number you inflated once contradicts itself the moment you publish an honest one next time.

"A number that won't collapse" is becoming a differentiator in itself

The more ARR inflation becomes the industry's standard operating mode, the more, conversely, the trust placed in a solo dev who breaks out real figures seems to rise. The reason indie hackers who post real numbers in the build-in-public context get support isn't the size of the number — it's the trust that the number won't fall apart later. In a market flooded with inflated figures, a modest number that doesn't collapse becomes the asset.

In my case, I've turned this into a few concrete rules. An MIT License OSS like gpdf has, by nature, a portion with zero direct revenue. The hosted API on top of it is a separate number. I try not to mix the two and say "gpdf does $X MRR." OSS download counts and stars are not revenue, so I don't bring them up when the topic is revenue. At the scale of doing micro SaaS on the side, a small number is the premise — so collapsing hurts far more than being small, in my view.

Common questions

Does ARR even matter for a solo dev?

If you're not raising funding, the absolute size of ARR doesn't mean much on its own, because it isn't a number you're showing to a VC. What matters is that the number you published still holds up when it's re-checked six months later, and that you always keep confirmed revenue and expectations separated in your own head. What the article's AI startups will eventually face is the snapback for the day the gap between CARR and ARR can't actually be closed. To avoid the same rut as a solo dev, what you need isn't the technique of looking bigger — it's the discipline of counting them separately from the start, I think.

Other notable reads today

• Project Glasswing: An Initial Update (Anthropic) A report that Anthropic's Mythos Preview, used with 50-plus companies including AWS and Google, found over 10,000 high and critical vulnerabilities in its first month. As AI sharply accelerates vulnerability discovery, the question becomes how OSS maintainers keep up the pace of fixes.
• AI is being used to resurrect the voices of dead pilots (TechCrunch) AI reconstructed the voice of a UPS pilot killed in a crash from a spectrogram, prompting the NTSB to temporarily restrict the release of investigation materials. In an era when the dead can be re-voiced, it makes you think about what principles a developer puts at the center of a design.
• Deno 2.8 (Deno Blog) Node.js compatibility test pass rate jumped from 42% to 76.4%, and npm install got 3.66x faster. It feels like the choices for a TypeScript runtime are genuinely widening.
• The Case for Design Disposables (Nielsen Norman Group) An argument for separating the rough "meant-to-be-thrown-away artifacts" designers make to aid thinking from polished deliverables. It reads as a way to split the exploration phase and the delivery phase in prototyping.
• Closing the Loop: What to Do After a Design Critique Ends (Nielsen Norman Group) A practical guide arguing that running a design critique isn't enough — closing the loop by reporting the resulting changes back to participants is what builds trust. It looks applicable to OSS review culture too.
• Smart ring maker Oura files to go public (TechCrunch) Smart-ring maker Oura filed with the SEC on 5.5 million units sold and an $11B valuation. As a case of getting this far on hardware subscription revenue, it's a useful reference for monetization design.

The next time I talk to anyone about renma's or gpdf-api's numbers, I'll split the confirmed portion from the expected portion before I open my mouth. Not inflating, it feels, is the cheapest differentiator that actually works.