Most teams don't plan to build localization tooling.
They arrive there accidentally.
It usually starts with a small set of strings, a few languages, and the reasonable assumption that this is mostly a one-time problem. Translate the files, check them in, move on.
At that stage, it is mostly fine.
The cost shows up later.
Early on, localization looks deceptively simple:
From an engineering perspective, this feels like solved territory. A few scripts, a bit of glue code, and you're done.
What's easy to miss is that localization isn't a feature. It's a system that has to stay correct over time.
Even a minimal in-house setup usually requires:
This rarely happens in one uninterrupted block. It's spread across sprints, wedged between other work, and context-switched heavily.
Conservatively:
At a typical fully loaded cost, that's roughly:
This isn't waste. It's real engineering work. It's just often invisible because it's folded into "feature development."
Once the system exists, reality starts to intrude.
Each issue is small. Each fix is reasonable. Together, they establish a pattern: this system needs attention.
After the initial build, localization becomes background work.
Typical ongoing tasks include:
This rarely feels expensive because it's rarely large in one chunk.
A common pattern looks like:
At ~$100/hour, that's roughly:
Just to keep things working. And that assumes nothing goes badly wrong.
Eventually, someone who isn't an engineer wants to help.
A native speaker notices an awkward phrase. A PM wants to tweak copy. Marketing wants consistency across languages.
At this point, most in-house systems start to strain.
Common outcomes:
None of this is hard. All of it interrupts engineering work.
This is usually when one person becomes "the localization person" by default. That role is rarely planned, documented, or scoped.
If you zoom out, the pattern is consistent across teams.
Very roughly:
The important part isn't the exact number. It's that the cost curve is open-ended.
Once you own the system, you own all of it.
There are cases where building in-house is the right call.
It often makes sense when:
In those cases, the system stays small and predictable.
The problem is that most teams don't stay in that state for long.
By the time teams start asking whether localization is "worth paying for," they've usually already paid part of the cost.
They've written scripts. They've fixed edge cases. They've debugged translation bugs they don't speak the language for.
The question usually isn't:
"Can we build this?"
It's:
"Do we want to keep owning it?"
That's not a technical question. It's a resource allocation decision.
And those are easier to make once the numbers are visible.
