· 11 min read

Most Indie Hacker Products Make Basically Nothing. About 5% Clear $8,000 a Month.

Building in Public Lessons

Every few weeks another post shows up with a screenshot of a Stripe dashboard and a caption like "solo founder, no employees, six figures a month." I've scrolled past dozens of these. What I don't see nearly as often is the denominator: how many people tried and got nowhere. The closest thing I could find to an actual answer, an analysis of 937 Stripe-verified products publicly listed on IndieHackers, found that more than 54% of them make no revenue at all, and only about 5% clear roughly $8,000 a month. That's the real population the highlight-reel posts get pulled from, and it looks nothing like a typical feed.

What the data actually shows once you get past the recycled blog posts

A "median $30 a month" figure has been making the rounds this year, usually paired with the "5% clear $8,000" line as if they came from the same clean survey. Both numbers trace back to the same source: a 2022 write-up from a web-scraping company called Scraping Fish, which pulled revenue numbers from 937 products that founders had listed on IndieHackers.com with Stripe verification turned on. I read the original piece directly. It states two things plainly in its own text: more than 54% of the products made zero revenue, and about 5% crossed roughly $8,333 a month, call it $100,000 a year. The $30 median gets repeated everywhere, including a Hacker News thread from 2024 that just links back to the same post, but that specific number lives in an interactive chart the article never restates in prose. I couldn't pin down where "$30" was first published as a stated figure rather than something a reader eyeballed off a histogram. Treat it as a widely repeated estimate, not a confirmed one. It's plausible given that over half the sample earns nothing, but I wouldn't defend the third digit of it.

There's a bigger issue than one shaky median, though: the 937 products are self-selected. Someone has to choose to post a project on IndieHackers, keep the listing current, and turn on Stripe verification, which is already a more committed group than the much larger population of people who start a side project on a random Tuesday and quietly abandon it three weeks later. If anything, the real distribution across everyone who ever tried is worse than what this dataset shows, not better.

The same shape turns up in an adjacent market with better data behind it. RevenueCat's 2026 State of Subscription Apps report, built from more than 115,000 mobile apps and $16 billion in tracked revenue, found that the top 5% of subscription apps now earn about 400 times more revenue than the bottom 25%, up from a 200x gap in 2024. The top quartile grew monthly recurring revenue by 80% or more year over year while the bottom quartile shrank by more than a third. Different market, mobile subscriptions instead of bootstrapped SaaS, but the same skew, and the gap is widening rather than closing.

The survivorship bias behind every solo founder growth story

None of this is an accident of what gets written about. A founder doing $40,000 a month has an obvious reason to post about it: it builds an audience, it markets the product, and it feels good to share. A founder who spent eight months on a project that made $340 total has no equivalent reason to write anything. There's no post titled "I built something, nobody wanted it, I quietly took the pricing page down." So the visible sample isn't just smaller than the real one, it's filtered specifically for outcomes worth bragging about, and every platform's ranking amplifies that filtered sample further, because a post about a big number gets more engagement than a post about nothing happening.

The damage isn't only that the story is unrepresentative. It resets what feels normal. If your reference class is a feed of $10,000-MRR announcements, a product making $400 a month after six months feels like failure, when by the numbers above it's already ahead of well over half the people who tried anything at all.

AI made building cheaper and getting noticed harder

The part of this narrative that's genuinely true right now: the cost of getting from idea to working product has dropped a lot. In March 2025, YC managing partner Jared Friedman said that a quarter of the accelerator's Winter 2025 batch had codebases where 95% of the code, measured by what a human typed versus what a model generated and not counting imported libraries, was AI-written. By his account these are highly technical founders who could have built the same product from scratch a year earlier and chose not to.

That's a real shift, but it's happening among well-funded, technically strong YC founders, not the median person building a side project after work, and it comes with friction. Stack Overflow's 2025 developer survey, based on responses from more than 49,000 developers, found AI tool adoption still climbing (80% now use these tools) while trust in the output is falling, from 40% a year earlier down to 29%. The top complaint, cited by 45% of respondents, was AI output that's "almost right, but not quite," and 66% said fixing that kind of code takes longer than writing it themselves would have. Even in a survey full of AI users, 72% said generating whole apps from a prompt, "vibe coding," isn't part of their actual professional work.

Put those two data points together and the real dynamic comes into focus. Building a working MVP is easier than it's ever been, if you have the judgment to catch what the model gets wrong. But building the MVP was rarely the bottleneck for most people who tried and failed. Getting someone who isn't your friend to open the product, over the noise of everyone else who also has a working MVP now, is the part that got harder, not easier, because the pool of people shipping something now includes everyone who used to be stopped by not knowing how to code.

What actually seems to separate the 5% from everyone else

I don't have a clean study that isolates this, so take it as reasoning built on the data above plus watching a lot of launches, not settled fact. The pattern that shows up repeatedly in products that do break out: the founder already had somewhere to post that wasn't a cold audience, a newsletter, a following built doing something unrelated, or a community they were already a trusted member of before they had anything to sell. Second, a niche narrow enough that a small number of specific people feel personally addressed by the product, instead of a broad category with ten well-funded competitors. Third, doing the unscalable work early: personally messaging the first fifty users, answering support in real time, watching people actually use the thing instead of only reading analytics. None of that is about the code. It maps directly onto why "building got cheaper" and "getting noticed got harder" are both true for the same person at the same time.

The honest take

If I were starting something new right now, I'd treat the first few months as an audience-building project with a product attached to it, not the other way around, and I'd pick a niche small enough that I could name twenty specific people who might want it. I'd also stop measuring the first year against $8,000 a month, because per the numbers above, hitting that puts you ahead of roughly 95% of everyone who tried, not behind.

Here's where I could be wrong: I'm implicitly treating $8,000 a month as the bar that matters, because that's the number the data actually supports. But if your real goal is a stable $2,000 a month product you run alongside other work, the survivorship-bias argument above cuts less than I'm making it sound. A boring product with fifty loyal customers and no growth ambitions might be a completely rational outcome, and this whole framing quietly treats it as a consolation prize when it might just be the goal. And for what it's worth, this blog isn't clearing anywhere near $8,000 a month either. I'm not writing this from outside the distribution looking in. I'm writing it from inside the 54%, which is exactly why I went looking for the real numbers instead of repeating the ones that show up everywhere else.

Author

Lukas

Sources

More Building in Public articles →

Stay in the Loop

Get new posts delivered to your inbox. No spam, unsubscribe anytime.

Newsletter coming soon. Set PUBLIC_CONVERTKIT_FORM_ID in .env to activate.

Related Posts