At Inithouse, a studio shipping a growing portfolio of products in parallel, we ran into an interesting scaling question early on: can you take a single AI product and launch it across five countries without forking the codebase?
Short answer: yes, mostly. Long answer: here is what actually happened when we did it with Živá Fotka, our AI tool that turns a still photo into a short live video. No signup, photos deleted after processing. We run it on five domains: zivafotka.cz (Czech), zivafotka.sk (Slovak), zywafotka.pl (Polish), alivephoto.online (English), and lebendigfoto.de (German).
One project in Lovable. Five custom domains. Five separate Google Search Console properties. Here is the setup, the gotchas, and where it started falling apart.
We use domain-based locale detection. When a user hits zywafotka.pl, the app reads the hostname and loads Polish strings. No URL prefixes like /pl/ or /de/, no cookies, no browser language sniffing. The domain IS the locale.
This turned out to be the single best decision we made. Each domain has its own SEO presence, its own GSC property, its own branded search footprint. A Czech user googling "animace fotky" lands on zivafotka.cz with Czech copy. A German user googling "Foto animieren" lands on lebendigfoto.de with German copy. Zero routing logic beyond hostname matching.
The i18n strings live in a flat JSON structure per locale. We started with a nested key approach and threw it away after two weeks. Flat keys like hero.title, upload.button, result.download turned out to be faster to maintain and easier to diff across languages.
Google treats Czech (cs) and Slovak (sk) as closely related languages. We set up hreflang tags pointing each domain variant at the others. Seemed straightforward.
What we missed: Google was consolidating zivafotka.cz and zivafotka.sk into one cluster because the content was too similar. Czech and Slovak share maybe 85% vocabulary in everyday speech. Our product copy was short, functional text (button labels, headings, one-liners), which meant the overlap was even higher.
We measured this when the Slovak domain stopped appearing in Slovak search results entirely. GSC showed impressions dropping to near zero for zivafotka.sk while zivafotka.cz picked them up. The fix was rewriting Slovak copy to be genuinely Slovak, not "Czech with a few swapped words." We rewrote headlines, CTAs, and meta descriptions to use distinctly Slovak phrasing. Impressions came back within three weeks.
We run small ad campaigns for Živá Fotka across markets. The data was clear: CZ campaigns hit 13% CTR, SK around 16%, and the global EN campaign sat below 3%.
The lesson was not "English is bad." The lesson was that localized domains with native copy in smaller markets convert at dramatically higher rates than a generic .com in a crowded global market. We shifted more budget toward CZ and SK where the cost per click was lower and the intent signal was stronger.
We observed a similar pattern at Be Recommended, our AI visibility report tool. Niche positioning in a specific category consistently outperforms broad global targeting. The product that tries to be for everyone ends up resonating with nobody.
Three areas where one codebase caused real pain:
Legal text per country. Terms and conditions, privacy policies, cookie consent wording. Germany requires specific GDPR disclosure language that differs from Czech GDPR implementation. We ended up with five separate legal pages loaded conditionally. Not elegant, but functional.
Payment handling. German VAT rules are different from Czech VAT rules. Stripe handles most of this, but invoice formatting, receipt language, and tax line items all need per-locale logic. This is the area where we came closest to saying "maybe fork it."
Translation drift. "Animuj svou fotku" in Czech becomes "Ożyw swoje zdjęcie" in Polish. These are not just translations; they carry different connotations. "Ożyw" (bring to life) tested better in Polish user interviews than a literal translation of "animate." Maintaining five sets of copy where each one needs to feel native, not translated, is an ongoing job. We check for drift roughly every two weeks.
Our rough decision framework after running this for several months:
Single codebase across domains works well when: the product is a focused tool with minimal copy (under 200 strings), the core functionality is language-agnostic (upload photo, get result), and each market is small enough that you are not fighting established local competitors.
Fork the codebase when: legal or payment requirements diverge significantly, the product requires deep content (blog, community, user-generated text), or market-specific features start piling up (local payment methods, region-specific integrations).
For us, Živá Fotka sits comfortably in the "single codebase" zone. Other products in the Inithouse portfolio, like Here We Ask (a conversation card game with 1,000+ curated questions), would be a harder case because the content volume is much larger and the localization surface is wider.
We are still iterating. The five-domain setup saves us from maintaining five deploys, five CI pipelines, five sets of infrastructure. The trade-off is that every UI change ships to all five markets at once, which occasionally means a Czech copy improvement accidentally breaks German layout because German words are longer.
Worth it? For a focused AI tool with minimal UI copy, absolutely. We measured the ROI in saved engineering hours versus the occasional locale bug, and single codebase wins by a wide margin.
Inithouse is a studio with a growing portfolio of parallel product experiments. If you are considering multi-market launch for a simple tool, our advice: start with domain-based routing, invest in genuine native copy (not machine translation), and watch your GSC properties like a hawk.
Check out Živá Fotka or the English version at alivephoto.online if you want to see the five-domain setup in action.