Most solo founders launch a second product too early. Pieter Levels is the exception, not the rule, and even he treats each product as separate. The decision is constraint-based — if you can’t clear the gates below, the answer is no.
Methodology. This guide draws on the public portfolio model documented by Pieter Levels in his levels.io blog and Twitter archive, plus solo-founder portfolio failure patterns described in Tyler Tringas’s writing on micro-SaaS. We have launched a second product once and abandoned the attempt twice. How we research.
The fantasy version of the solo-founder portfolio looks like Pieter Levels: five products, each at meaningful MRR, all running on autopilot. The reality version looks like a founder with one stagnant product and one half-built second product, neither of which is growing. Most founders try the fantasy. Most end up at the reality. The difference is whether they cleared a specific set of constraints before starting.
Treat these as gates, not guidelines. If even one is locked, do not start. The cost of starting too early is months of split focus and two products that go sideways instead of one that grows.
Below $5K MRR, your first product still needs your full attention. The growth from $1K to $5K is the hardest stretch in solo SaaS, and splitting focus during it almost always means you don’t finish either climb. Stable means MRR has grown month over month for at least three consecutive months — not a single good week.
Distribution is the moat for solo founders. A second product that sells to a different audience means you start audience-building from scratch — the most expensive thing in early-stage SaaS. If the second product can be sold to the same email list, the same Twitter following, the same Slack community as the first, the launch path is dramatically shorter.
If you’re still personally answering every support ticket on product one, you do not have the bandwidth for product two. Either automate (canned responses, helpdesk macros, AI-assisted triage) or hire a part-time support contractor. The mental tax of context-switching is the silent killer of multi-product solo founders.
If the build estimate is over two months, you’re building a company, not a portfolio addition. The scope must be small enough to ship while still maintaining product one. The right second product is closer to a productised side-project than a full SaaS — and ideally rides on infrastructure (auth, billing, email) you’ve already built.
Notice that none of these conditions are about whether the second product is a good idea. The market for the idea is necessary but not sufficient. The constraints above are about whether you, right now, have the capacity to pull it off without losing the first product.
The pattern is so consistent it’s almost a law of physics. Product one stops growing — usually because of a sales/marketing problem, not a product problem. Founder gets bored. Founder convinces themselves a new product will be more fun and more lucrative. Founder spends three months on product two while product one’s churn quietly accelerates. Six months later, product one is at 70% of its peak MRR and product two has reached $400 MRR.
The diagnostic question to ask before launching product two: have you exhausted the growth tactics on product one? Most founders launch a second product because they’ve exhausted their interest, not their tactics. Those are not the same thing.
The fix isn’t to never launch a second product. The fix is to be honest about why you’re launching it. If the answer is “because product one is boring,” that’s information about your psychology, not your strategy.
Many proposed second products are actually features of the first product in disguise. The test is whether the new thing solves a problem for the same customer. If yes, build it inside the existing product — you get the distribution for free, the cross-sell is automatic, and the support overhead doesn’t double.
The classic example: an AI writing tool whose customers ask for an “AI image generator.” The wrong move is to build that as a separate SaaS. The right move is to add it as a tier or a credit-pack to the existing tool. Same customer, same checkout, same support inbox — just more revenue per account. We covered the cross-sell math in our zero to $1K MRR playbook.
The flipside example: a productivity tool for designers whose creator wants to launch a hiring marketplace for the same designers. Different customer (companies, not designers), different unit economics (transaction fees, not subscriptions), different go-to-market. That one’s a product, not a feature.
Solo founders consistently overrate the importance of the next product idea and underrate the importance of the audience they’ve already built. If your first product has 1,000 paying customers and a 5,000-person email list, you have a distribution asset that any second product would benefit from — and that any net-new launch would have to recreate from scratch.
The strategic question isn’t “what should I build next?” It’s “what would my existing customers also buy?” The first question is romantic; the second is profitable. Cross-sell, upsell, and tier expansion almost always beat net-new launches at solo founder scale. They’re less exciting, but the conversion math is much better.
This is the same insight we covered in when to niche down vs broaden — the second product, done well, broadens the offering without broadening the audience. That’s the move that compounds; widening both at once is the move that fails.
Pieter Levels is the canonical example of a solo founder running multiple products. His public model is worth studying precisely because it’s the opposite of what most founders attempt. The rules below are extracted from his blog posts, tweets, and various podcast appearances.
Nomad List for digital nomads. Remote OK for remote jobs. Photo AI for AI portraits. The audiences overlap on the founder’s personal Twitter, but each product has a clearly defined niche it dominates rather than fighting for general traffic.
Each product has its own checkout, its own pricing, its own subscription. There’s no “bundle” that ties them together. This means each product must be economically viable on its own — no subsidising one with another.
Each product is its own technical artefact. Levels has explicitly avoided building shared platforms, micro-services, or unified backends across products. The cost of decoupling is real; the cost of coupling (a shared bug, a shared scaling issue, a shared security incident) is much worse.
The products link to each other in footers and occasional tweets, but Levels does not push existing customers from one product into another. Each product earns its own customers through its own merit. This avoids the credibility damage of feeling like a marketing list.
The lesson buried in these rules is that Levels treats each product as a separate business that happens to share a founder. Most solo founders who try to build a portfolio attempt the opposite — they try to leverage the first product into the second through shared code, shared accounts, and shared marketing. The leverage is real on paper and almost never plays out the way the founder hopes.
Before you start writing code for product two, write a one-page launch plan. The plan must answer:
If the kill criterion is uncomfortable to write, that’s information. The founders who succeed with multiple products are the ones who can kill an underperforming second product cleanly. The founders who fail are the ones who keep both alive at half-MRR forever, paralysed by the sunk cost.
Almost every “should I launch a second product” question collapses into one of three answers, depending on how the founder honestly answers the gates above:
For more context on which kinds of solo SaaS products actually compound, see our micro-SaaS examples roundup and our list of AI SaaS ideas for 2026. The difference between a portfolio that compounds and a graveyard of half-finished products is, almost always, this single decision: when to start the second one.
The stack, prompts, pricing, and mistakes to avoid — for solo founders building with AI.