We run 16 products at Inithouse. All on Lovable. All backed by Supabase. One team managing all of it. That number sounds impressive until you realize it also means 16 custom domains, 16 Supabase projects, 16 sets of edge functions, and 16 chances to make the same mistake over and over.
Here are the five technical mistakes that cost us the most time, and how we fixed each one.
Mistake 1: Every Supabase schema was a snowflake
Our first three products had completely different table names for the same things. User analytics in one project lived in page_views. In another, analytics_events. A third used user_activity. Auth tables had different column names. Blog tables varied wildly.
When we wanted to write a shared stats endpoint, we had to write custom queries for every project. A task that should have taken one afternoon took two weeks.
The fix: We built a shared migration template. Every new product gets the same base tables: analytics (with standardized columns for page views, events, referrers), blog_posts (title, slug, content, published_at), and a consistent auth setup. Old projects got retrofitted one by one during quiet weeks.
Now adding a monitoring endpoint to something like Pet Imagination or Watching Agents takes 20 minutes instead of a day.
Mistake 2: Custom domains break after Lovable publishes (and nobody notices)
Lovable lets you connect a custom domain. Works great. Until you hit Publish and the deploy pipeline does something that quietly breaks DNS verification. The Lovable preview URL works fine, the deploy succeeds, you get a green checkmark. But your actual domain shows a certificate error or a blank page.
We lost three days of traffic on one product before someone checked the live URL. The preview was fine. The custom domain was dead.
The fix: A post-publish checklist. After every Lovable publish, we open the live custom domain in an incognito window and verify it loads. We also added a simple uptime check (just curl the domain every 5 minutes from a cron job) that pings Slack if it gets anything other than a 200.
It sounds basic. It is basic. But when you have 16 domains, "I'll just check it" becomes "I forgot to check it" very fast.
Mistake 3: Zero centralized monitoring
For months, if we wanted to know how Be Recommended was doing compared to Voice Tables, someone had to open two separate Supabase dashboards, two GA4 properties, and mentally combine the numbers.
Nobody did that regularly. We were flying blind across the portfolio.
The fix: A stats API endpoint deployed to every Supabase project. Each product exposes a /functions/v1/stats edge function that returns key metrics in a standardized JSON format: total users, signups this week, page views, top referrers. An aggregator script pulls from all 16 endpoints and dumps the result into a single dashboard.
The total investment was one edge function template (reusable thanks to the schema standardization from Mistake 1) and a 50-line aggregator. Should have done it on day one.
Mistake 4: Copy-paste components without adapting them
Lovable generates React components. When you have a working card component in one project, the temptation is obvious: copy it to the next project. We did this constantly.
The problem: copied components carry assumptions. A pricing card from Magical Song assumed a one-time payment flow. We pasted it into a subscription product and spent two days debugging why Stripe webhooks were failing. The component was calling a one-time checkout endpoint that did not exist in the new project.
We also ended up with slightly different versions of the same component across products. A bug fix in one project never propagated to the others.
The fix: We stopped copy-pasting raw components. Instead, we maintain a reference doc of component patterns. When a new project needs a pricing card, we describe the requirements to Lovable from scratch, referencing the pattern doc for structure. The AI generates a fresh component that fits the new project's stack.
Slower to set up. Faster to maintain. Zero phantom bugs from stale assumptions.
Mistake 5: Treating Lovable's AI chat as documentation
Lovable stores the entire chat history for each project. Every decision, every prompt, every "change the button color" lives there. We treated this as our documentation: "It's all in the Lovable chat."
The problem shows up when you need to know why a decision was made six weeks later. Lovable chat is chronological and mixed with failed attempts, reverted changes, and tangential experiments. Finding "why did we switch from Stripe to LemonSqueezy on this product" in a 200-message chat thread is miserable.
The fix: We moved decision logging to Linear. Every meaningful technical decision gets a one-line comment on the relevant issue: what changed, why, and what it replaced. Lovable chat stays as the execution log. Linear holds the decision log.
Searching "LemonSqueezy" in Linear takes two seconds. Searching it in Lovable chat across 16 projects takes an afternoon.
The pattern behind all five
Every mistake is a variation of the same thing: treating 16 products like 16 separate projects instead of one portfolio. Standardize early, monitor centrally, and document outside the tool you build in.
If you are running multiple Lovable projects (or multiple projects on any AI builder), start with the templates and monitoring before you start building product number three. We waited until product number eight. Do not be us.
All 16 products are live at inithouse.com.
Top comments (0)