I've spent years advising development teams on internationalization, and one pattern keeps repeating: teams discover the cost of postponing i18n work far too late. The experience of my fellow member at the LangOps Institute, Rémi Auxenfans, captures the problem better than anything I could describe:
"Over 20 years building localization infrastructure at one of Canada's largest software companies taught me a lot. And two projects in particular stick with me because they perfectly show what’s at stake. In both cases, development teams faced the same challenge: launch internationally within six months. The outcomes couldn’t have been more different.
The first team had postponed internationalization for years. When expansion arrived, they discovered hundreds of hard-coded strings, UI components sized only for English, and date logic locked to one locale. The system rebuild consumed months, translators billed extra for fixing inconsistencies, developers spent weeks fixing bugs buried in years-old code… and launch postponement became inevitable.
The second team took a different path from the very beginning. They externalized strings immediately, designed flexible layouts, and introduced pseudo-localization before real translations existed. When launch came, multilingual versions shipped alongside English without any emergency fixes and delays. There was just one difference between both teams: the second treated internationalization as infrastructure rather than something that could wait."
☝️ Internationalize even when you’re not ready to localize 🔗
Let's clear up a common misconception: localization and internationalization are not the same thing. While localization is the output your users ultimately interact with (translated content, adapted formats, and culturally appropriate messaging), internationalization represents the infrastructure that makes localization possible. It's what developers build.
This is why you can't localize a product that hasn't been internationalized, but you can internationalize a product you don't plan to localize yet. And that's exactly where you save money in the long run.
When you internationalize from day one, you're preparing your codebase to support multiple languages and regions even if you only ship in English initially. Basically, when you skip this step, you're building a house without a foundation for the second floor you'll eventually need. 😬🏗️
You can't localize a product that hasn't been internationalized, but you can internationalize a product you don't plan to localize yet. That's where you save money in the long run
Why internationalization debt isn’t "just" tech debt 🔗
Once you understand that internationalization is the cornerstone and localization is the layer that sits on top, the difference becomes clear. With regular technical debt, you're improving something that already works. You might take shortcuts in the dev process to ship faster, knowing you'll tidy things up later.
Internationalization debt is different. You're not making something work better. You're making something work for entire populations who currently can't use your product at all. And the cost of catching up grows faster than most teams expect.
I usually ask development teams a question that makes them uncomfortable:
I'm not being rhetorical. I ask because I've seen what happens when teams finally face that reality. Everything seems manageable at first, and a few hundred code updates might seem like a week of work. 🤷🏽♂️ But those updates don't stay contained. They spread across years of feature development, buried in modules developers wrote and forgot about long ago. And as the work multiplies, what looked like straightforward cleanup becomes months of rebuilds that touch every corner of your product and blocks everything else your team needs to ship.
Postponing i18n is a market blocker for SaaS 🔗
No business environment makes the impact of internationalization debt more visible than SaaS, where it directly affects the entire business model. SaaS products live and die by seamless user experience. When someone signs up, they expect everything to simply work for them, regardless of their language or region. If it doesn’t, you lose something more than a single customer: you lose credibility in an entire market.
This happens more often than you'd think. I've tested apps in Arabic that looked polished in English but became completely unusable the moment I switched languages. This didn't happen because of bad translations… the interface literally collapsed when text spilled off screen, navigation broke, and buttons shifted out of view. The product simply wasn't built to handle anything beyond English, and as a result, that company doesn't exist in Arabic-speaking markets.
For SaaS specifically, internationalization debt creates various challenges:
- Releases become nightmares: Every feature you ship needs to work in every language you support. If your infrastructure wasn't built for this, each release becomes a localization project instead of a deployment.
- Users expect real-time updates: Automated translations, even when occasionally flawed, create more trust than delayed "perfect" translations that leave users behind. But automated translation only works when your system can handle it.
- Every friction point multiplies: Poor translations might get a shrug, but poor internationalization breaks the product. That's when support tickets pile up, eating resources and slowing teams down at every touchpoint.
Postponed i18n creates structural problems that become harder and more expensive to unwind later. These issues usually appear small and isolated, but they compound as your product expands
By the time you're ready to 'fix' internationalization, you've already capped your growth. But what exactly falls apart when you skip it?
👻 3 common i18n tech debt horror stories 🔗
My colleague Rémi has identified three specific technical patterns that create the most pain for development teams. These examples stem from real issues he's encountered repeatedly while building localization infrastructure for products serving 24 languages:
1. Hard-coded strings buried in codebases 🔗
This is a classic i18n struggle. Rémi recounts that, during one project, his team discovered the login module alone contained mixed keys like login.button, BTN_LOGIN, and auth.signinButton. Each developer had followed a different pattern. Over time, this created nine separate "Log in" or "Sign in" strings across 14 languages. "Translators billed extra for repetitive content, QA flagged terminology mismatches in every release, and Japanese and German users began telling us they were confused", he says. "The interface language felt inconsistent to them, and they couldn't figure out why the same action had different labels depending on where they were in the application."
"This seemed harmless when the codebase was small. But imagine the refactoring required when that grows to a million lines… Multiply that shortcut by years of feature development = you end up with content scattered everywhere, impossible to extract cleanly when expansion finally arrives."
Once the company standardized the naming into a simple, predictable structure and merged duplicates, the results became concrete: fewer translation units, cleaner code reviews, and a measurable drop in global support incidents tied to inconsistent language.
2. Text stitched together in code that breaks in every other language 🔗
English developers often write constructions like "You have " + count + " new messages". It works in one language, but breaks in almost every other. The pattern simply becomes unmaintainable once pluralization rules, gender, and word order enter the picture.
"After converting these cases into proper message templates with parameters and locale-specific plural logic, the team saw immediate improvements: translator escalations stopped, layout inconsistencies disappeared, and last-minute requests to 'shorten' text for UI constraints became very rare", says Rémi.
3. Architecture that assumes one language 🔗
The third common problem is companies building their entire systems around assumptions that only work for English. This includes module and component interactions, as well as reading direction. This was the case of a settings panel he worked with, which had pixel-fixed widths for buttons and labels. "It was beautiful in English, but completely broken in German and Arabic", Rémi recalls.
To avoid costly one-off fixes, the company introduced pseudo-localization for the next sprint: "Things got way easier then because designers could suddenly see expansion, diacritics, and mirrored layouts in their prototypes before translators touched any files. Everyone involved was relieved they could catch layout issues during design rather than QA. It was a single, small change that shifted the development culture and changed everyone's routines for the better."
Companies tend to build their entire systems around assumptions that only work in English. This leads to problems with UX components and reading direction later on. Prototyping early avoids the problem
🤦🏽 The excuses we hear about early internationalization 🔗
Teams of every size and stage use surprisingly consistent reasoning to postpone internationalization. We hear these frequently:
"We're focused on our local market right now" 🔗
Fair point. But even "local" markets have international users. A Spanish SaaS product will attract immigrants, tourists, and international employees working in Spain. You're already serving multiple languages without realizing it yet.
More importantly, focusing on your local market doesn't mean you'll stay there forever. No one builds a product thinking, "I will never leave this country." Even if your plan is not to expand now, you need to prepare for it. You need to put it in your product plan. Every decision you make going forward should consider how it affects internationalization.
"We don’t have the budget" 🔗
This one is extremely common. What I usually say is that, although you might object with insufficient resources, you actually can't afford not to look into this now, because you won't be able to afford it later. It's just going to be too expensive, and/or will have consequences in your team's capacity and resources (imagine having to face a whole structural revamp of bigger architecture when you finally decide to localize).
"Our developers are overloaded with features and bugs" 🔗
Sure. Every startup is resource-constrained. You're under pressure, releasing new things, fixing bugs, doing things all the time. It's understandable that you may not have the capacity to do it straight away.
But just as you do with everything else in your software stack and in your product plan, you need to weigh out the pros and cons of not doing it now versus spending some time on it to save yourself in the future. It's like preparation for anything. Would you prepare for a camping trip by getting all the stuff you need beforehand, or just figure things out when you get there?
"We're not going international, so why bother?" 🔗
If that's where you want to stay and that's your sole focus, then genuinely don't bother. But honestly, if you ran a business, would you really plan to stay in one country forever?
💭 Questions you should ask before deciding 🔗
If you've worked through the common objections and still aren't sure whether internationalization should be a priority, a few simple questions can clarify your direction.
1. What’s your long-term growth plan? 🔗
Every team says they want to grow, even if they're "focused on the local market" for now. If your roadmap includes expansion beyond your current country, even if it's two years away, you need the infrastructure that makes that expansion possible. Good UX in other languages starts in how you build the product today.
Do you envision going outside of your current market? If yes, then the answer is you have to internationalize. The same way you're building the user experience in the source language, the same way you have to do it for others. Otherwise you won't exist in those markets.
2. Can you afford the scaling cost? 🔗
Your codebase won't stay small. It might feel manageable now, but it usually becomes way more complex as you add features, components, and contributors. You can always internationalize later, but refactoring costs escalate with every update.
Think about your product roadmap for the next two years. Every module, every component you build today either makes future internationalization easier or considerably harder. If it doesn't have proper internationalization, then every time you try to implement a new feature in the languages you want to support, you will come across problems.
3. How much rework are you willing to accept? 🔗
Teams rarely enjoy large-scale refactoring. If your honest answer is "as little as possible", then the most efficient move is building with internationalization in mind from the start. This way you avoid a potential months-long overhaul that freezes other development.
😣 What to do if you already have the debt 🔗
If you've realized your product already carries internationalization debt, don't panic. Many teams learn this late, and it's still completely fixable. What matters now is approaching it methodically.
1. Understand where you are 🔗
The first step is a cliché solution for solving such problems: understand what the problem is. You need to see where you are, what you have and what you don't have.
2. Set a specific goal 🔗
Set a goal for yourself. Say "I want to expand into these specific markets." Pick specific targets. If you want to go to Japan, China, or Egypt, each of these countries has their own requirements and complications because of scripts and writing systems. When you pick specific targets, you get answers and you get a definition of what the specific challenges are.
Once you have those targets, think about what you need if you want to go there now. This question can be answered by someone in your network or by looking online for an expert in internationalization. There are lots of people who can do consultations for this, assess your situation, and give you advice on what can be done and where you can go. Or you can do reading in general. There are so many resources that explain the problems and challenges, like:
- This official Unicode standards guide
- The Unicode CLDR Project
- The complete React Intl docs
- This article about React i18n by Jessy Mussoko
- This hands-on i18n guide by Julia Díez
- This list with Unicode Consortium specialists you can contact
Use whatever resources you have and see how far you can go. But if you get stuck quite early in the process, for whatever reason, then definitely engage a professional consultant
3. Prioritize by impact 🔗
Given the resources you probably have, you're not going to solve the problem straight away. But at least you can make it less problematic and consequently more manageable in the future.
Start with what directly blocks your goals, where it would make the most impact, and how to implement it. You don't have to go all in at once. For example: users can tolerate rough edges in settings screens, but they won’t tolerate a broken signup. Similarly, a bit awkward or unpolished text is likely to have a lower priority than poor navigation causing confusion and zero product adoption.
4. Baby steps are enough 🔗
Start small, learn what works, identify what's difficult, and apply those lessons to the next piece. Bit by bit, build your understanding of what is required. The more you learn about it, the more you'll understand its importance, and the more it will affect your decision to say "okay, now that I know about this, we need to implement it as soon as possible."
5. Use standard solutions 🔗
Everyone internationalizes eventually. It's either the hard way or the easy way. The solution is there. You don't have to reinvent the wheel. You don't have to recreate something specific for you. There are standardized solutions that everyone can use.
You don't need to build internationalization infrastructure from scratch. You just need to be aware, have some prototypes, do some testing. Don't push it to production yet: just keep it there so you know. Spend an hour just learning about this and do a few things to see how it works.
6. Plan like any feature 🔗
Plan it just like any of your features and any of the items on your product plan. Just plan it and see how it would work. Treat internationalization as infrastructure work that enables future features. Put it in your roadmap, assign capacity, set milestones, and track progress. Treat internationalization like the essential work it is, not as a side project developers tackle when they have spare time.
🦺 Start with structure, everything else follows 🔗
I once spoke with a CTO whose video editing product served primarily English-speaking users. They chose not to translate their entire interface into Arabic or Hebrew, but they built their system to handle right-to-left subtitles from day one, because users from those markets needed to edit their own content. That single architectural decision meant they could serve customers in dozens of countries without limiting what those customers could create.
That's what internationalization enables. You don't have to support every language immediately. What you do need are systems that won't break when you add them. When that's done, adding languages becomes routine deployment, not a multi-month project. Expansion happens on your timeline, not when accumulated debt forces your hand.
The companies that succeed internationally are usually the ones who built foundations that made localization straightforward.
