Running 14 products on the same stack sounds like a scaling nightmare. It's not. It's actually the only thing keeping me sane.
The stack
Every product at Inithouse runs on three layers:
Lovable for the frontend. React SPAs, component library, built-in Cloudflare Pages deployment. I don't write boilerplate. I describe what I want, iterate in real time, and hit Publish. A new product goes from idea to live URL in hours, not weeks.
Supabase for the backend. Postgres with Row Level Security, edge functions for anything custom, real-time subscriptions where needed. The SQL editor alone saves me from building admin panels for half the products.
Cloudflare Pages for hosting. Every Lovable publish pushes to CF automatically. I add a custom domain, set up _headers for cache control and content types, and that's it. Global CDN, no config.
Analytics: GA4 for traffic, Microsoft Clarity for session replays and heatmaps.
Why this works for solo building
The whole point is speed of iteration. When you're validating 14 MVPs, you don't need the perfect architecture. You need to ship, measure, and decide fast.
Magical Song went from concept to paying customers in a single weekend. Same stack as Be Recommended, which targets a completely different market (AI visibility for brands). The shared foundation means bug fixes in one product often improve another.
Supabase edge functions handle the weird stuff: AI song generation triggers, LLM API calls for visibility scoring, payment webhooks. All in TypeScript, deployed in seconds.
Where it breaks
No SSR. Lovable builds React SPAs. That means client-side rendering only. For SEO-heavy products, this hurts. I work around it with Cloudflare Workers for meta tags and pre-rendering, but it's a patch, not a solution.
Supabase edge functions have cold starts. Not terrible (200-500ms), but noticeable on first load for latency-sensitive features.
Shared patterns create coupling. When I update the blog system on one product, I'm tempted to update all 14. Sometimes that's efficient. Sometimes it introduces bugs in products I haven't touched in weeks.
Lovable's AI chat sometimes hallucinates component structures. When it works, it's magic. When it doesn't, you spend more time debugging generated code than you'd spend writing it from scratch.
The trade-off I made
The obvious alternative: Next.js + Vercel. Better SSR, better SEO out of the box, mature ecosystem.
I chose Lovable because iteration speed beats architectural purity when you're searching for product-market fit. Once a product finds traction, migrating the frontend is a known problem. Not finding PMF because you spent three months on infrastructure is a dead-end problem.
Fourteen products, three tools, zero regret about the boring parts.
Jakub, builder @ Inithouse
Top comments (0)