Stop Optimizing for MRR. The Number That Decides Whether Your Solo SaaS Survives Is the Margin — and in 2026 It's Quietly Lower Than the Screenshots Suggest.
The screenshot is always the same. A revenue graph going up and to the right, a number ($10K MRR, $30K MRR), and a caption about momentum. What the screenshot never shows is the number that actually decides whether the person posting it still has a business in eighteen months: the margin. Two solo SaaS products can both read $10K MRR and be living completely different lives, because one keeps $8,500 of it and the other keeps $4,500. MRR is the number people post because it's the flattering one. Margin is the number that survives.
This matters more in 2026 than it did three years ago, and the reason is specific: AI costs turned a lot of software businesses from near-zero marginal cost into something that actually meters per use. The 90%-margin software business was a real thing when your only variable cost was Stripe's fee and a few cents of compute. The moment your product calls a model on every action, your cost of goods scales with usage, and the margin everyone assumes is baked in starts leaking somewhere most founders never look.
The distribution nobody screenshots
The roundups floating around in 2026 (and I'd treat these as directional, not gospel, because they come from content-marketing lists rather than audited studies) put the shape of micro-SaaS outcomes somewhere like this: a large chunk never clears $1K MRR and gets abandoned, a thick middle plateaus in the low thousands, a smaller slice reaches $5K–$20K, and only a thin top tier breaks $20K and becomes a real lifestyle business or an acquisition target. Take the exact percentages with salt. The shape is right, and it's the part the timeline hides, because failed and plateaued products don't post.
But even that distribution is an MRR distribution, which means it's still telling you the flattering number. Layer margin on top and it gets sharper. Those same sources put typical bootstrapped micro-SaaS net margins across a wide band: strong operators clearing the high end, plenty sitting closer to the middle once you actually subtract everything. The number to internalize isn't any single percentage. It's that the average is materially lower than the 90% everyone assumes, and the difference is made of costs that don't show up until you go looking.
Where the margin actually goes
For a solo operator in 2026, the leaks are predictable and they're mostly new.
Token and inference cost is the big one, and it's insidious because it scales with success. The more people use the AI feature you shipped to win customers, the more it costs you to serve them. A feature that's cheap at 50 users can be a meaningful cost line at 5,000, and because it grows with usage rather than landing as a fixed bill, you can be celebrating a usage spike and a margin compression in the same week without connecting them.
Then there's the stack tax: the gateway, the vector store, the monitoring, the auth provider, the email sender, the background-job runner, each one a reasonable $20–$50 a month that collectively becomes a number you've stopped reading on the invoice. Add payment processing, which is a clean few percent off the top of every dollar, and merchant-of-record fees if you use one, which are a few percent more. None of these are wrong to pay. All of them are margin you're not counting if your dashboard only shows MRR.
Why margin beats MRR for a one-person business
Here's the part that's specific to being solo rather than a funded startup. A funded company can run thin margins and buy growth, because the bet is that scale fixes the unit economics later and investors are funding the gap. You don't have that. You are the runway. Every point of margin you give up is money that doesn't reach you, and there's no Series A coming to bridge it.
That changes what "growing" means. A funded founder optimizes for MRR because the next round is priced on it. A solo operator should optimize for take-home, because the only thing that keeps the business alive is whether it pays you enough to keep working on it. A $6K-MRR product at 85% margin pays you better than a $10K-MRR product at 45%, and it does it with fewer customers to support, fewer support tickets, and less infrastructure to keep running. Lower MRR, better business. The screenshot would never tell you that, which is exactly why you shouldn't run your business off other people's screenshots.
What I'd actually do
Track gross margin monthly, in the same place you track MRR, with the same prominence. Not once a year at tax time: every month, as a first-class number. If you can't say what your margin was last month within a couple of points, you're flying on the flattering metric.
Put a ceiling on token and inference cost as a percentage of revenue, and treat breaching it as a signal to either fix the cost or change the price, not a thing to absorb quietly. Price so that AI cost is an explicit line item you've accounted for, not a surprise that eats the margin you thought you had: if a feature costs you real money per use, the price has to carry it. And before you chase the next MRR milestone, ask whether the marginal customer is actually accretive or whether you're buying revenue at a margin that makes you poorer the bigger you get.
The honest counter-take: early on, margin is the wrong obsession, and I don't want to pretend otherwise. When you're hunting for product-market fit, you should be spending freely on whatever helps you learn fastest, eating ugly margins to ship and iterate, and ignoring the unit economics on purpose. Optimizing margin before you have a product people want is a great way to build an efficient business nobody buys from. The point isn't that margin matters from day one. It's that the moment you have something real, margin is what turns it into a business you keep, and most build-in-public advice never makes that switch because the audience rewards the MRR screenshot, not the boring monthly margin line that actually predicts who's still standing next year.
Author
Lukas
@lukcombinator