The failure modes of solo SaaS are remarkably predictable. After watching thousands of indie launches, the same five mistakes appear in the same order, year after year.
How this essay works. This is a diagnostic, not a checklist. We’re tracing five patterns we see across post-mortems on Indie Hackers, public failure write-ups from MicroConf alumni, and the Pieter Levels school of public-by-default building. How we research.
The most accurate sentence ever written about indie SaaS is from a now-deleted Indie Hackers thread: “I didn’t fail in some new and creative way. I failed exactly how everyone said I would, in exactly the order they said I would, and I still couldn’t see it happening at the time.”
That sentence captures something important. The interesting thing about solo-SaaS failure is not that it happens — the base rate is high and always has been — but that the failure is so legible. There is a pattern. The pattern is not hidden. It is documented in hundreds of public post-mortems, summarized in MicroConf survey data, and replicated across cohorts of founders who have never met one another.
What follows is the failure sequence. Not a randomized list of mistakes — an ordered sequence. Founders fail in step one before they fail in step two. They fail in step two before step three. The earlier you can recognize where you are in the sequence, the more options you still have.
This is the most common failure, and it is the one founders are most resistant to admitting they made.
What it looks like: you spent six weekends building. You have a polished landing page, a working dashboard, OAuth flows that actually work, and a Stripe integration that handles dunning and proration correctly. You launched. You have four signups. Three are friends. The fourth signed up to look around and never came back. You are now arguing with yourself about whether the problem is the headline copy.
The headline copy is not the problem. The problem is that nobody asked for this product, you didn’t verify that anyone wanted it before building it, and the four-signups-after-launch outcome is the universe correctly registering “I have not heard of a problem that this thing solves.”
Why this happens: building feels like progress. Talking to potential customers feels like rejection. Founders who came from engineering backgrounds, especially, default to the activity that they’re competent at. The cost of this preference is enormous because validation, done correctly, takes 48 hours. Building a polished product takes 200. The ratio of regret to invested time at month four is brutal.
What successful founders do instead: they get a hand-raise before they write code. A hand-raise means a real person, not previously known to them, who has heard the pitch and said “yes, I would pay for that, when can I see it?” Pieter Levels has written publicly about how he used to do this with one-tweet validations and a Stripe link before the product existed. The product was built only after the conversion data justified it. We’ve written this protocol up in how to validate a SaaS idea in 48 hours.
The diagnostic question: before you wrote a single line of code, did at least 10 strangers tell you “yes, I would pay” in a way that did not involve them being polite to you? If the answer is no, you are in failure mode one. The fix is not to ship harder. The fix is to stop and validate, with the product you already have if it’s built, or with a Figma mockup if it isn’t.
This is the rarest failure on the list, but the most expensive when it happens. Founders who hit this one tend to do so once, badly, and never recover.
What it looks like: you built something on weekends. It got 200 signups in the first month. Twenty of them paid. You did the math — if this scales linearly, you’ll be at $20K MRR in a year. You quit your job. Six months later you are at $1,200 MRR, growth has flatlined, and you’re burning $4K/month of personal savings. The problem is not that the product is bad. The problem is that you confused launch-week novelty traffic for product-market fit.
Why this happens: the dopamine of a successful launch week is genuinely indistinguishable from the dopamine of a real product taking off. The shapes of the early curves look identical. The difference only becomes visible at month two or three, when one curve continues compounding and the other plateaus. Founders who quit at week six often do so on a curve that hadn’t separated yet.
What successful founders do instead: they hold a higher bar before quitting. Marc Lou, Tony Dinh, and Danny Postma have all written publicly about waiting for sustained, unhyped revenue — usually $5K–$10K MRR for at least three consecutive months — before treating it as a real business. The point is not the dollar amount. The point is the duration. Real product-market fit is the absence of decay, not the presence of a spike.
The diagnostic question: how does your MRR look three months after launch, with no help from a Product Hunt feature, no influencer post, and no time-limited launch discount? If you don’t have that data yet, you don’t have evidence of PMF. You have evidence of a launch. Don’t conflate them. We’ve written more on the pre-quit calibration in when to quit your job for SaaS.
This is the failure mode of competent builders. It is the most psychologically painful on the list because the work was real, the work was good, and the work was completely wasted.
What it looks like: you got to $800 MRR. Growth slowed. You read on Twitter that “successful SaaS has team features.” You spent three months building a multi-seat collaboration system with role-based permissions, invitation flows, and a workspace switcher. You shipped it. Nobody used it. Three months of life are gone, and your MRR is still $800 because the bottleneck was never collaboration. The bottleneck was top-of-funnel.
Why this happens: founders who can’t ship features confuse activity with progress. Founders who can ship features make the slightly more sophisticated mistake of confusing the wrong activity with progress. They build the feature that another founder told them would be important — or that some VC blog post said was the “next milestone” — without checking whether their specific bottleneck is feature-shaped at all.
The bottleneck of a SaaS product is rarely the absence of feature X. It is more often: nobody knows the product exists; the people who know it exists don’t understand the value; the people who understand the value don’t convert because the price or pricing structure is wrong; the people who convert churn after 60 days because the product’s actual usefulness is shallower than the marketing claims. None of those bottlenecks are fixed by features.
What successful founders do instead: they spend ruthless effort identifying which of those four bottlenecks is theirs, and fixing only that one. Patrick McKenzie’s old Kalzumeus essays are the foundational reading on this. He documented — against his own engineering instincts — that the highest-ROI activity in early SaaS is almost never building. It is usually a one-week project to fix funnel attribution, run an SEO audit, or write a single highly-specific landing page for one customer segment.
This is the most common late-stage failure. It happens to founders who survived modes one, two, and three. They built the right thing. They didn’t quit too early. They focused on the right bottleneck. And then they stopped doing distribution.
What it looks like: you launched. You did Product Hunt. You did Hacker News. You did a Twitter thread that went semi-viral. You got to $3K MRR off the launch wave. Eighteen months later you are at $4K MRR, and the only customers you’ve added are ones who Googled their way to your landing page. You don’t know why. You’re tired.
Why this happens: launches feel like the marketing strategy. They are not the marketing strategy. They are a one-time event that creates a brief spike of attention, after which the actual ongoing distribution work has to begin. Most solo founders never make that transition. They post once a week on Twitter, they update the blog “when they have time,” and they assume that the product will sell itself if it’s good enough.
The product will not sell itself. There is no evidence in the entire history of software businesses that products sell themselves at indie scale. The founders who appear to have products that sell themselves are, on closer inspection, doing 6–15 hours of distribution work per week and making it look invisible. Tony Dinh ships products and then methodically posts build-in-public updates for 12–18 months. Marc Lou writes weekly. Pieter Levels has been tweeting consistently for a decade.
What successful founders do instead: they treat distribution as a permanent function of the business, not a launch-week project. They pick one channel, commit to it for at least 6 months, and measure conversion from that channel weekly. The channel might be SEO, Twitter, YouTube, a podcast, or community-driven. It almost never matters which one. It always matters that it’s sustained.
The distribution rule of thumb at indie scale: if you cannot identify a specific channel responsible for at least 30% of your new signups in the last 60 days, you do not have a distribution strategy. You have luck. Luck runs out.
The final failure is the slowest and the cruelest. It happens to founders who survived all four previous modes. They built the right thing. They held on through PMF ambiguity. They focused on the right bottleneck. They sustained distribution. And then they slowly drifted into a mode where they were busy every day, exhausted every week, and not actually growing the business.
What it looks like: you reply to support tickets within an hour. You ship a small feature every two weeks. You write a newsletter monthly. You post on Twitter daily. You feel productive. Your MRR has been at $4,500 for nine months. When asked “what are you doing this quarter to grow the business by 50%,” you cannot answer the question. You can only describe what you are doing this week.
Why this happens: solo SaaS, by its nature, generates an enormous volume of small, urgent-feeling tasks. Customer support tickets feel urgent. Bugs feel urgent. Twitter notifications feel urgent. The work that actually moves the business — pricing experiments, channel expansion, content compounding, segment expansion — feels less urgent because there is no deadline and no immediate consequence. So it gets postponed. Forever.
What successful founders do instead: they ruthlessly distinguish operating work (keeping the business running) from growth work (making the business bigger). They measure how many hours they spend on each. They protect growth-work time from operating-work creep. They batch support to once or twice a day. They say no to feature requests that don’t map to growth. We’ve documented this in our zero to $1K MRR playbook, but the same logic applies at every stage.
The patterns of solo founders who survive year one and reach a sustainable business are surprisingly consistent. Across the public post-mortems, MicroConf survey data, and the Indie Hackers $10K-MRR-club archives, the surviving founders share four characteristics.
They validated before building. The build came after the hand-raise. Not the other way around. They might have lost a few weekends to validation conversations, but they did not lose six months to a product nobody wanted.
They sustained 12–18 months of low signal. They did not quit at month four when growth was ambiguous. They did not panic at month seven when MRR was flat. They held on long enough for the distribution work to compound and for the product to find its real customer segment, which is almost never the segment the founder targeted on day one.
Distribution was a default, not an afterthought. They wrote, posted, shipped publicly, or spoke from week one. They didn’t treat marketing as something that would happen later, when they had time. Marketing was woven into how they built. Each feature shipped was content. Each customer conversation was raw material.
They focused on revenue, not users. The vanity metric of free signups was treated as ambient noise. The real metric was paid customers, and within paid customers, expansion revenue and retention. They were comfortable with smaller, paying audiences and uncomfortable with large, unpaid ones.
Run through this list honestly. Each item is a failure mode in the sequence. The earliest unchecked item is the most likely place your business is breaking right now.
Solo SaaS is not failing because it’s a hard business model. The business model is fine. Solo SaaS is failing because most founders execute a known sequence of mistakes and don’t recognize the sequence while they’re inside it.
The five failures — build-before-validate, quit-too-early, wrong-feature, no-distribution, activity-instead-of-progress — are documented, repeatable, and predictable. The founders who survive don’t survive because they’re smarter or luckier. They survive because they recognized which step they were about to fail at, and corrected before they fell through it.
The hardest part of writing this is that none of it is new. Every paragraph above has been written by a dozen founders before, in slightly different language, on slightly different blogs, with slightly different examples. The information is not the bottleneck. The bottleneck is the founder, sitting in front of a quiet dashboard, refusing to admit which step they’re on.
The stack, prompts, pricing, and mistakes to avoid — for solo founders building with AI.