Technical Mistakes of Running 16 Products on Lovable and Supabase
We run 16 products at Inithouse. We use Lovable and Supabase for all of them. One team manages everything.
Managing 16 products means 16 custom domains, 16 Supabase projects, and 16 sets of edge functions. This scale leads to repeated mistakes.
Here are five technical mistakes we made and how we fixed them.
- Inconsistent Database Schemas Our first three products used different names for the same data. One project used page_views for analytics. Another used analytics_events.
Writing shared tools took two weeks instead of one afternoon because we had to write custom queries for every project.
The fix: We built a shared migration template. Every new product uses the same base tables for analytics, blog posts, and auth.
- Silent Domain Failures Lovable lets you connect custom domains. Sometimes the deploy succeeds but the DNS verification fails. The preview URL works, but the live domain shows a blank page.
We lost three days of traffic on one product before we noticed.
The fix: We use a post-publish checklist. We open the live domain in an incognito window to verify it. We also use a cron job to ping the domain every five minutes.
- Fragmented Data Visibility To see how our products performed, we had to open separate Supabase dashboards and GA4 properties. We were flying blind.
The fix: We deployed a stats API endpoint to every Supabase project. Each product uses an edge function to return key metrics in one format. A simple script pulls data from all 16 endpoints into one dashboard.
- Copy-Pasting Components We used to copy React components from one project to another. This caused bugs. A pricing card from one project assumed a one-time payment. When we pasted it into a subscription project, it broke the Stripe flow.
The fix: We stopped copy-pasting code. We maintain a document of component patterns. We tell Lovable to build a fresh component based on those patterns. This prevents bugs from old assumptions.
- Using Chat as Documentation We used Lovable chat history as our documentation. Finding a specific technical decision in a long chat thread is difficult and slow.
The fix: We moved decision logging to Linear. Every major technical change gets a comment in Linear explaining what changed and why. Lovable chat stays for execution. Linear stays for decisions.
The lesson: Do not treat 16 products as 16 separate projects. Treat them as one portfolio. Standardize your templates and monitor everything centrally.
Source: https://dev.to/jakub_inithouse/technical-mistakes-of-running-16-products-on-lovable-supabase-59fh