When to Internationalize a SaaS and How Not to Regret It

Internationalization looks like a checkbox feature. Add a language dropdown, wrap strings in a translation function, ship. Then a year later the marketing team wants French SEO pages, the sales team wants German legal terms, and every new feature costs 30% more to build because every string needs three approvals. This is the version of the i18n conversation we have with founders before they commit.

The wrong reasons to add i18n early

Most founders add internationalization for reasons that don't hold up.

"We might expand to Europe next year"

You probably won't. Or if you do, you'll expand to the UK first, which speaks English. Actual multi-language expansion usually happens 18-36 months later than founders plan, and rarely to the languages they expected.

"Our biggest customers are in Germany"

If they're paying you in English, they're fine with English. German-speaking B2B buyers overwhelmingly work in English tools every day. Consumer products are different; B2B rarely is.

"It'll be harder to add later"

Sort of true, but not the way founders mean. Retrofitting i18n into a codebase takes 2-4 weeks with modern tooling. Building it early and maintaining it for two years before it drives revenue costs much more in translation fees, engineering overhead, and product velocity.

The right reasons to add i18n

Your buyer requires localized product

Government, healthcare, some regulated verticals, and specific geographies (France, Japan, China, Quebec, parts of Latin America) genuinely require localized product for buyer approval or legal compliance. If that's your buyer, i18n moves from "nice to have" to "unblocks the deal."

You have real evidence of language friction

Signup drop-off from specific countries. Support tickets asking for translations. A pattern of trials starting and going quiet in specific geographies. Real evidence beats speculation.

Your marketing strategy requires SEO in other languages

If your growth model depends on ranking for local-language keywords, product i18n is a byproduct of a marketing decision. Own it as that.

You're building for a consumer market outside the US

Consumer expectations differ. A Brazilian consumer app that only ships English is dead on arrival. A B2B SaaS selling to Brazilian ops teams in English is usually fine.

What "add i18n" actually means

The three costs founders underestimate.

String extraction and management

Every user-visible string needs to be pulled out of the code and into a translation file. That's the easy part. The harder part is keeping them in sync — every new feature adds strings, every string needs translation, every translation needs to be applied before the feature ships in that locale.

Translation workflow

Machine translation is a starting point. It's not a shipping product. Real localization involves human translators, review cycles, and glossaries for product-specific terms. Tools like Lokalise, Phrase, or Crowdin handle the workflow but they cost real money at scale.

The formatting problem

Dates, numbers, currencies, pluralization, address formats, phone numbers, name orderings. Every locale has quirks. Formatting libraries help, but designers still have to think about how a UI holds when strings get 40% longer in German or need right-to-left flow in Arabic.

The minimum viable i18n implementation

What we ship on projects that actually need it:

1. A translation function wrapper around every user-visible string.
2. Translation files per locale in JSON or PO format.
3. A locale detection layer — from URL, user preference, or Accept-Language header.
4. Date, number, and currency formatting through Intl APIs.
5. A CI check that flags untranslated strings.
6. A translation management tool integrated with the workflow.

That's the minimum. Below it, you don't really have i18n. Above it, you're gold-plating for scale you don't have.

Framework choice

i18next / react-i18next

Battle-tested. Works everywhere. Rich pluralization and interpolation support. Larger bundle than newer options. Reasonable default for React apps.

next-intl

Best-in-class for Next.js apps. First-class support for locale-based routing (which is critical for SEO), smaller runtime, better DX. Doesn't help outside Next.

FormatJS / react-intl

Older, still solid, closer to the ICU MessageFormat standard. Verbose. Use it if you're already committed.

Lingui

Compiler-based approach. Extracts strings from JSX with a Babel plugin. Elegant when it works, painful when the tooling drifts. Small but committed user base.

SEO and localized routing

The part that turns i18n from a code change into a marketing decision.

If you're localizing for SEO, you need locale-specific URLs — /en/, /fr/, /de/ or subdomains. Every localized page needs its own canonical URL. Hreflang tags on every page telling search engines about the language versions. Localized meta tags. Localized structured data.

That's a lot of surface area, and getting it wrong is worse than not doing it — misconfigured hreflang can hurt your English pages too.

Common mistakes

Machine translation without human review. Google Translate is a great starting point. It's not the product. Buyers can tell within seconds when a UI has been machine-translated, and it damages trust.

Ignoring RTL languages. If Arabic or Hebrew is on your roadmap, RTL support isn't a translation issue — it's a design system issue. Layouts flip. Icons flip. Some things don't flip. Plan for it or don't target those markets.

Not budgeting for maintenance. Every new feature adds strings. Every string needs translation. Every translation needs review. A localized product costs 20-40% more to ship features into.

Localizing legal terms without a lawyer. Translating "Terms of Service" is not the same as legally valid terms in the target market. If localization is for compliance, involve counsel.

Building i18n before finding product-market fit. Localization compounds the cost of every experiment. Products still finding their shape shouldn't add that overhead.

The pragmatic sequence

What we typically recommend for clients considering i18n:

1. Ship in English first. Get to product-market fit.
2. Watch trial data by country. Note where drop-off correlates with language.
3. When one geography represents 15%+ of trials or a specific enterprise deal requires localization, commit.
4. Start with UI translation for one locale, not five. Ship, measure, then decide about the second locale.
5. Only localize marketing and legal pages after the product itself is fully translated for that locale.

Trade-offs

Localized product opens markets, and it also raises support cost. Every language is another support queue, another sales cycle in a different time zone, and another set of documentation to maintain. A team of 5 shouldn't run 6 languages. A team of 30 might.

Localization also constrains speed. When every feature has to wait for translation before shipping to some users, feature velocity slows. Some teams solve this by shipping English-first with a fallback to English for untranslated strings; others hold releases until all locales are ready. Both are defensible; know which you're picking.

Common misconceptions

"We can auto-translate at runtime." Live machine translation of user-facing UI reads as amateur. It's fine for user-generated content, never for product chrome.

"i18n is a one-time project." It's a permanent workflow. Every new string added anywhere costs translation effort forever.

"English-only limits our TAM." True in some markets, false in most B2B. Buyers in English-fluent geographies (Nordics, Netherlands, most of enterprise Europe, Israel) work in English tools daily.

Frequently asked questions

Final take

Internationalization is a real project, not a checkbox. Add it when you have evidence a real customer segment needs it, not because it feels responsible. When you do add it, start with one locale, use proper tooling, and budget for ongoing translation work. Skip the temptation to future-proof — retrofitting i18n later is much cheaper than maintaining it for two years before it matters.

If you're weighing whether to internationalize, book a call. We've helped clients on both sides of that decision.