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. This sounds good until you face 16 custom domains, 16 Supabase projects, and 16 sets of edge functions.
We made mistakes that cost us time. Here are the five biggest technical mistakes and our fixes.
- Inconsistent database schemas
Our first three products used different table names for the same data. One project used page_views for analytics. Another used analytics_events. This made it impossible to write shared code. A task that should take one afternoon took two weeks.
The fix: We built a shared migration template. Every new product gets the same base tables for analytics, blog posts, and auth. We retrofitted old projects during quiet weeks. Now, adding a monitoring endpoint takes 20 minutes instead of a day.
- Broken custom domains
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 because we did not check the live URL.
The fix: We use a post-publish checklist. We open every live domain in an incognito window to verify it. We also added an uptime check that pings Slack if a domain fails.
- Fragmented data visibility
We could not see how our whole portfolio performed without opening separate dashboards for every product. We were flying blind.
The fix: We deployed a stats API endpoint to every Supabase project. Each product sends key metrics like users and signups in a standard format. A single script pulls this data into one dashboard.
- Copy-pasting components
We used to copy React components from one project to another. These components carried old assumptions. A pricing card from one product failed in another because it expected a different payment flow. We spent days debugging these phantom bugs.
The fix: We stopped copy-pasting. We maintain a document of component patterns. We tell Lovable to build a fresh component based on these patterns. It is slower to set up but much easier to maintain.
- Using chat history as documentation
We relied on Lovable chat history to remember technical decisions. Chat logs are messy. They mix successful changes with failed attempts. Finding a specific reason for a change in a long thread is hard.
The fix: We moved decision logging to Linear. We write one line in Linear explaining what changed and why. Lovable chat is for execution. Linear is for decisions.
The lesson is simple. Do not treat 16 products like 16 separate projects. Treat them like one portfolio. Standardize your templates and monitor everything from one place.
Source: https://dev.to/jakub_inithouse/technical-mistakes-of-running-16-products-on-lovable-supabase-59fh
Optional learning community: https://t.me/GyaanSetuAi