Running 17 MVPs with a 3-person team: our stack and workflow
We run 17 products at Inithouse right now. All early-stage MVPs hunting for product-market fit. People keep asking how three people manage that many experiments without going crazy, so here's the actual breakdown.
The stack and workflow
Every product gets built the same way. Lovable for the frontend (React SPAs), Supabase for the backend, Linear for project management. That's it. No custom infra, no Kubernetes, no microservices. Each product takes 2-3 days to get from idea to live URL with a real domain.
We tried mixing tools early on. Different frameworks for different products, a couple of WordPress sites, one Django backend. Killed all of that within two months. Standardizing the stack cut our context-switching cost in half.
The weekly rhythm looks like this: Monday we check metrics across all products (GSC, GA4, Clarity). Tuesday through Thursday we build whatever the data says matters most. Friday we publish, measure, plan the next week. Most weeks 2-3 products get active work. The rest just sit there collecting data. An MVP pulling 200 organic visits per month with zero maintenance is still a valid experiment running.
How we decide what lives and what dies
Every product gets 30 days after launch. We track three things: organic traffic trend, user engagement (session duration + return visits), and conversion signals (signups, purchases, whatever the product's core action is).
If a product shows zero traction after 30 days, we kill it. No second chances, no "maybe we should try a different landing page." Dead. We've killed 4 products this way since January.
If something shows any signal at all, even 50 organic visits trending upward, it stays alive and gets another cycle of attention. Right now Be Recommended (AI visibility scoring for brands) is showing the strongest traction. Party Challenges (browser-based conversation card game) keeps growing organically. And Voice Tables (voice-controlled workspace) just got its first repeat users.
What I'd tell someone considering the portfolio approach
The biggest mistake we made was trying to scale three products at the same time last March. We had strong early signals on three different MVPs and split our attention three ways. Made meaningful progress on none of them. Now the rule is simple: one product gets growth focus per sprint. The others get maintenance only.
The portfolio approach works, but only if you're disciplined about killing. Most founders I talk to can't let go. They'll keep feeding a product for 6 months because they spent 3 weeks building it. That's the trap.
The math is pretty straightforward. If each MVP costs you 3 days to build and you kill 70% within a month, your cost per surviving experiment is about 10 days of work. Compare that to spending 6 months on one idea that might not work.
Full portfolio at inithouse.com. Happy to answer questions about the stack, the kill framework, or anything else.
The "kill within 30 days, no exceptions" rule is the part most people skip when they copy the portfolio approach. Standardizing the stack to cut context-switching cost is underrated too. Even with a process this disciplined, I'd bet something across 17 products still occasionally falls through a crack nobody's watching that week, that's the gap FounderFlow tries to close for me across my own businesses. Curious what happens when two products show signal in the same week, how do you pick which gets the sprint?
This is a great breakdown. What stood out to me most is not the number of products, but the discipline around standardizing the stack and killing experiments quickly.
A lot of founders can launch multiple MVPs, but very few can avoid becoming emotionally attached to each one. The 30-day kill rule seems like the real advantage here.