Portfolio Strategy for Solo Founders: When to Launch Product #9 (And When to Stop)
How many SaaS products can one founder run? The honest framework.
Three weeks ago I opened a fresh Notion doc, typed "Product #9 - Concept" at the top, and stared at it for twenty minutes before closing the tab. Then I got distracted by a support ticket. Story of my life.
I've been running 8 active SaaS products at Velocity Digital Labs with a 1 founder + 1 manager team. The portfolio includes ClickzProtect ($99/mo flat for click fraud detection), JustEmails ($49/year flat for unlimited email hosting), and JustBrowser (antidetect browser on a custom Chromium 146 engine — not extension-based, actual C++ integration). Eight products. Bootstrapped. No VC, no platform-play fantasy.
Should there be a ninth? I genuinely don't know.
The honest answer is complicated — and honestly, I'm probably not the best person to answer it objectively because I'm too deep in my own mess. But here's the framework I've built for making that decision.
What and Why: The Multi-Product Question
Every bootstrapper eventually faces this fork. You've got one product working (or mostly working), and you see another opportunity. Do you go deep? Or hedge and launch something new?
The studios I respect — Tiny, Late Checkout, XO Capital — have shown that the portfolio model works. But here's what they don't tweet about: it's not for everyone. There's a specific set of conditions where adding another product makes sense, and a much larger set where it's just procrastination dressed up as strategy. (I've been guilty of the latter. More than once.)
Why does this matter right now? The barrier to launching has never been lower. Claude Code, Railway, Stripe, Cloudflare — you can go from idea to functioning SaaS in a weekend. I've done it. The question isn't "can I build another product?" The question is "should I?"
Core Concepts: The Portfolio Framework
Before we get into the when-to-launch decision, there are a few ideas you need to internalize. I learned most of these the hard way.
Marginal attention is what matters. Your first product gets 100% of your attention. Your second doesn't get 50% — it gets whatever scraps are left after the first one's fires are out. By product three or four, each new addition is fighting for maybe 10-15% of your headspace. The math is sublinear. Most founders don't realize how fast it compounds. I certainly didn't.
Revenue weighting is the only honest prioritization. Every morning I check revenue across the portfolio. Whichever product generated the most yesterday gets my first two hours. The smaller products go into maintenance mode — bug fixes only. This sounds cold. It is. But the alternative is emotional decision-making: "JustBrowser is more fun to work on" while ClickzProtect's enterprise customers wait for the feature they're paying for.
Shared infrastructure is non-negotiable. Every one of our 8 products runs on the same stack: Next.js 15, TypeScript, Postgres (Neon or Railway-hosted), Cloudflare for DNS and CDN, Stripe for billing. All of them. The moment you introduce variety — "this one's on Vercel, that one uses Firebase" — you're creating context-switching debt. Context-switching is the silent killer of multi-product founders.
The team model caps your ceiling. We're a 1 founder + 1 manager operation. I handle the AI-assisted engineering. He handles partnerships, support escalations, vendors — the human operational work. Without that split, I'd max out around 3 products. With it, we've scaled to 8. But we're near the ceiling. Adding another human would change the math again. We haven't. Hiring is its own special hell, and I'm not ready for it.
The Complete Process: When to Launch vs. When to Stop
Here's the decision framework I've been refining for the past year.
Signs You Should NOT Launch Another Product
Your support queue owns your mornings. If customer support takes more than 2 hours daily across your existing products, you're already at capacity. Adding another inbox is just adding another way to disappoint people. We hit this wall after VeloCalls launched — suddenly three products had active support queues and I was spending half my day in email. Not building. Not shipping. Just... email.
Your highest-revenue product is stagnating. Look at your best performer. When did it last ship a meaningful feature? If the answer is "I can't remember" or "over a month ago," you're already neglecting the thing that's actually working. I made this mistake with VeloCards — it was getting organic signups, I ignored it for six weeks while building JustBrowser. Momentum gone. My fault entirely.
You're launching to avoid the hard work. This is the uncomfortable one. Sometimes the next product isn't opportunity — it's procrastination. Scaling an existing product is hard. The features are bigger, the edge cases nastier, the competition paying attention. Launching something new feels fresh and exciting by comparison. Be honest: is "product #9" strategy or escape? I've had to ask myself this three times this year alone.
Your infrastructure isn't automated. If you're still manually deploying, manually checking dashboards, manually triaging alerts — you don't have the operational leverage to add another product. We built the unified monitoring layer with JustAnalytics (which replaced GA4 + Sentry + Datadog + Pingdom + LogRocket across everything) before we launched products 6-8. The infrastructure came first. See how we approach multi-product architecture for more on this.
Signs You MIGHT Be Ready for Another Product
Existing products run on autopilot for weeks. When I can ignore VeloCards for two weeks and nothing breaks — no bugs, no support escalations, steady signups — that's a signal. The product has matured past "needs constant attention." Most products don't get here for 12-18 months. Some never do.
The new product shares 80%+ of your existing stack. If product #9 would use the same hosting, same database pattern, same auth system, same billing integration as products 1-8, the marginal complexity is low. If it requires new infrastructure — different hosting, different payment processor, APIs you've never touched — that 80% drops fast.
You have genuine demand signals, not just ideas. Ideas are cheap. Waitlists are better but still cheap. Actual prepayment, enterprise LOIs, or clear evidence you're solving a problem people are already paying someone else to solve — that's a real signal. DevOS has a public waitlist, but we haven't rushed to launch. Waitlist ≠ willingness to pay. I've learned that lesson before.
You've honestly assessed your attention capacity. How many hours per week do you actually have for product work? Not calendar hours — real, deep-focus hours after meetings, admin, and life. Divide that by your existing product count. If the answer is under 5 hours per product per week, you're stretched. Adding another denominator doesn't help. It just makes each slice thinner.
The Portfolio Math Nobody Talks About
Here's the part that's hard to admit publicly. It makes me uncomfortable to write it.
A solo founder running 8 products is not building 8 exceptional products. They're building maybe 2-3 products that get real attention, 3-4 in maintenance mode, and 1-2 that should probably be sunset but haven't been.
That's the honest state of our portfolio. ClickzProtect and JustAnalytics get the bulk of active development. VeloCards and JustBrowser are in feature-freeze except for urgent fixes. JustEmails is mostly stable — email hosting doesn't need constant iteration once it works. VeloCalls is growing slowly but getting minimal attention. DevOS is still in development with a waitlist. The parent studio site (velocitydigitallabs.com) exists mostly as a portfolio hub.
Is that bad? Genuinely don't know. The portfolio thesis says it's fine — you're betting on a few winners, not perfection across the board. But it also means customers of the lower-priority products are getting a slower iteration cycle than they'd get from a focused competitor. That bothers me sometimes. I try not to think about it too much.
This is the tradeoff most multi-product founders don't talk about: you're choosing breadth over depth. That's a real cost. And you're making that choice on behalf of your customers, not just yourself.
Advanced Tips: What I'd Tell My Past Self
Don't count paused products in your "active" number. Three of our products — VelocityPay, FairTravels, and The Glassware Company — are paused. Internal-only, waiting on certifications, or deprioritized for strategic reasons. They exist on the portfolio page, but they're not in the active 8. Be clear about what's alive and what isn't, both publicly and to yourself.
Revenue doesn't equal attention requirements. A product generating steady revenue with stable churn might need less attention than a smaller product in growth mode. ClickzProtect's enterprise features require more engineering time than JustEmails' entire roadmap — even though both contribute meaningfully to the studio.
The "should I launch another" question is almost always "no." I've learned to apply a 2-week cooling-off period to new product ideas. If I'm still excited after two weeks of not working on it, maybe it's real. Most ideas don't survive that filter. The Notion doc I opened three weeks ago? Still empty.
Sunset before you launch. If you're at capacity but see a genuine opportunity, the answer isn't "launch anyway." It's "sunset something first." Kill a product, sell it, or put it in explicit hibernation. Make room. We haven't been disciplined enough about this ourselves — which is partly why product #9 hasn't happened. I'm bad at killing things. Working on it.
Common Mistakes
Confusing "I built it" with "I'm running it." Building a product is the easy part. Running it — support, maintenance, security patches, feature requests, billing issues — is 10x the work over time. Most founders count "launched" and stop there. Launching is maybe 20% of the job.
Treating all products as equal. Equal attention across an unequal portfolio is a recipe for mediocrity everywhere. Pick your winners. Let them win. The others get maintenance mode.
Optimizing for portfolio size instead of portfolio quality. "I run 10 products" sounds impressive on Twitter. Means nothing if 7 of them are half-built, unprofitable, or embarrassing. Ask me how I know.
Launching adjacent products when you should be going deep. If your click fraud detection product is working, the answer probably isn't "launch an email product next." The answer is probably "add the enterprise feature your paying customers are asking for." We've gotten this wrong multiple times. Still getting it wrong, probably.
Not killing products fast enough. Every product in your portfolio has maintenance costs — even the ones you've stopped developing. Security patches. Domain renewals. Support emails from confused users who found an old landing page. If something isn't working and won't work, shut it down. We've been too slow here.
Frequently Asked Questions
How many SaaS products can a solo founder realistically manage?
Most solo founders max out at 3-4 products before quality tanks. Beyond that requires extreme stack standardization, automation, and usually at least one other person handling ops. We run 8 active products with a 1 founder + 1 manager team, but 2-3 of those are in maintenance mode at any given time.
What signals tell you it's time to stop launching new products?
Three clear signals: your support queue takes more than 2 hours daily, your highest-revenue product hasn't shipped a meaningful feature in 6+ weeks, or you're losing deals to competitors who are shipping faster. When you see these, your portfolio has hit capacity.
Should you focus on one product or build multiple?
Depends on your risk tolerance and goals. One product means higher stakes but deeper focus. Multiple products spread risk but split attention. The studio model works for bootstrappers who want diversified revenue streams, but it's objectively harder to build a huge outcome this way.
When does adding another product actually make sense?
When you've genuinely automated 80% of ops on your existing products, when the new product shares infrastructure with what you already run, and when you're not launching just to avoid the hard work of scaling what you have. Honest self-assessment matters more than ambition here.
Resources and Next Steps
If you're thinking through the multi-product decision:
- JustAnalytics — what we use for unified monitoring across everything. One dashboard, one under-5KB script, no per-product bills. Check out the JustAnalytics blog for setup guides.
- Railway makes multi-product hosting actually manageable
- VeloCards — our digital business card product, and a good example of a product that can run on autopilot
The question isn't really "how many products can I run?" It's "at what quality level, with what tradeoffs, and for what purpose?" Answer that honestly, and the number takes care of itself.
Product #9 will happen when the timing is right. Or it won't. That Notion doc is still waiting. Might stay that way.
Follow the Studio
Velocity Digital Labs is a multi-product studio building 8 active SaaS products with a 1 founder + 1 manager team. Bootstrapped. No VC platform-play — just shipping.