Beyond the Remix: A Multilingual Setup for Lovable That Actually Scales

A few months ago I wrote a post called The "Vibe Coding" Breakthrough about an afternoon I spent with Lovable. I'd built a complete fractional executive services site between morning coffee and dinner, and the rush of that day, of suddenly being able to ship things I would once have outsourced to a developer for weeks, made the whole post read like a love letter.

A few months and a few production sites later, I want to write about the part the love letter skipped over.

What happens after the first launch, when the second language version goes live, and then the third, and you start to notice that you haven't actually built one site. You've built four near-identical sites that drift further apart every time you touch any of them.

If you're about to remix your Lovable project into another language, or you've already done it a few times and you're starting to feel the weight, this is for you.

The Remix Trap

Lovable's remix feature is a gift. It hands you a perfect copy of an existing project that you can mold into something new, and for a second language version, that is exactly what you want.

The catch is in the word "copy." The moment you remix, you have two completely independent projects. There's no umbilical cord back to the original. As far as Lovable is concerned, the two projects are strangers. By the time you have four of them, say a .com, a .de, a .nl and a .se, you don't really have one product in four languages. You have four near-identical products that drift further apart every time you change any one of them.

Update your hero copy? Three projects to update. Add a testimonial? Three. Fix a typo on the pricing page? You already know.

And the drift isn't polite. The same prompt produces subtly different output in each project. A button labelled "Get started" in one quietly becomes "Start now" in another. Five months in, the four sites read like distant cousins instead of one brand in four markets.

That part is what most founders underestimate. The drift doesn't show up in your bug tracker. It shows up in the gap between how your German site reads and how your Swedish site reads, and the customer who lands on both will notice before you do.

The Four Ways Out

There are roughly four ways to handle this, ranked by how much they actually solve the problem.

1. Keep mirroring your prompts. Make the change in project A, then re-run the same prompt in B, C and D. This works for a week. It doesn't work for a year. You'll forget one. The AI will re-interpret the prompt and produce something subtly different. You end up reconciling more than you build.

2. Sync via GitHub. Connect each Lovable project to GitHub and manually copy commits between them. Cleaner than re-prompting, but it requires comfort with git, and it turns every product update into a chore. Fine for developers. Miserable for marketers.

3. A shared component library. Extract your common pieces into a separate repo that each project pulls from. Conceptually elegant, completely overkill for a marketing site, and it just adds a new maintenance surface of its own.

4. One project, multiple domains. This is the one that actually solves it. You collapse all your country sites into a single Lovable project. The site detects which country domain it's being loaded from and serves the right language automatically. One codebase. One source of truth. One place to change anything.

Make a change in one place, see it on every site. That's the whole point.

What "One Project, Many Domains" Actually Looks Like

Imagine a fictional brand. Brightwell, a cozy home goods company operating in four countries.

• brightwell.com (default, English)
• brightwell.de (Germany)
• brightwell.nl (Netherlands)
• brightwell.se (Sweden)

All four domains point at the same site. When a visitor types brightwell.de, the site notices it's loading on a .de domain and serves German. The translations live in plain text files inside the project, one file per language, that anyone can edit. The language switcher in the header doesn't toggle a hidden state. It actually sends the visitor to the matching country domain. Click "Nederlands" on brightwell.de and you land cleanly on brightwell.nl, on the same page, just translated.

For you as the founder, the workflow is simple. Open one Lovable project. Make one change. Hit save. Watch it appear on four sites.

What About the Stuff That Genuinely Differs Per Country?

This is the part where most multilingual setups overcomplicate themselves, and it turns out to be simpler than people expect.

Things that differ per country fall into two clean buckets.

The first is stuff that needs translation. Hero headlines, button labels, product descriptions. Those live in translation files, one per language.

The second is stuff that's just configuration. Prices, currencies, partner shop links, support email, cookie banner provider. Those live in a single config file with a section per country.

So Brightwell's German config might say: use German translations, prices in euros, link to the German distributor, support email hallo@brightwell.de. The Swedish one says: Swedish translations, kronor, the Swedish distributor, hej@brightwell.se. It's one small lookup table. You write it once and you're done with it.

The Migration

The hard part of this isn't the technology. It's deciding to stop adding to the parallel-projects pile and spending one focused day untangling what's already there.

Roughly, the work looks like this.

1. Pick your strongest Lovable project as the canonical one. Whichever is most current, best designed, most up to date. The other language versions become donors of translated text, nothing more.
2. Connect it to GitHub. Lovable has a one-click integration in project settings.
3. Prompt Lovable to add the multilingual setup. Something like: "Add react-i18next, detect the language from the domain name, and update the language switcher to redirect to the correct country domain." Lovable will do most of this for you.
4. Paste in the translations from your other projects. Open each old language project, copy the strings, drop them into the new translation files.
5. Deploy through Vercel or Netlify. Both are free hosting providers that let you alias multiple custom domains onto a single project. Lovable's built-in hosting can't do that.
6. Update DNS at your registrar. Point each country domain at Vercel.
7. Test the whole thing, then archive the old projects. They become read-only museums you can safely retire.

A capable non-developer can do all of this in a focused day with a bit of help. The pay-off is permanent. You never have to make the same change in three places again.

The Honest Trade-off

You're trading "everything happens inside Lovable" for "Lovable plus GitHub plus Vercel." Three free tools instead of one. That's a real change in your workflow, and it'll feel like more moving parts at first. After about a week, it stops feeling that way and starts feeling like one clean pipeline.

The other trade-off is worth naming, and it's about SEO. Because Lovable projects are single-page apps, the language detection happens in the browser, not on the server. For a marketing site, that's fine. If your business depends on dominating local search rankings in each country, you'll eventually want a server-rendered framework underneath. Don't worry about that on day one.

The Lesson

Vibe coding made it cheap to spin up a second site. It did not make it cheap to keep four sites in sync.

The remix is a brilliant first move. It's a much worse fourth move. The earlier you consolidate, the less translation work you have to do twice. If you're already at three or four language versions and you can feel the drift starting to bite, this weekend is a good weekend to do something about it.