The real cost of i18n: build vs buy

Internationalization always has a cost. The real question isn’t “how much does a platform cost?” but “how much does my homegrown i18n already cost — and where is that cost hiding?” Most teams underestimate the second one because it never shows up on an invoice: it’s paid in engineering hours, production bugs, and markets reached too late.

Let’s do the math honestly, with numbers and time — no FUD. The goal isn’t to conclude “always buy,” it’s to give you a framework to decide. The figures below are illustrative: adjust them to your rates and your context.

The visible cost: building your own i18n

At first, homegrown i18n looks trivial — a JSON file and a t() function. But a real localization pipeline takes much more:

• text extraction and loading per namespace;
• plurals and ICU rules per language;
• interpolation, language fallback, locale detection;
• regional formats (dates, numbers, currencies);
• writing-direction handling (RTL).

For a capable team, that baseline is already 5 to 10 engineering days. At a $600/day rate, that’s $3,000–6,000 before a single word is translated. That’s the visible cost — and it’s the smallest one.

The hidden costs

This is where the budget slips, because these line items never stop.

• Maintenance. The homegrown system has to keep up with framework upgrades, new edge cases, new languages. Budget 1 to 3 days a month, indefinitely.
• The ad-hoc translation workflow. With no platform, developers export files, send them to translators, re-import, resolve conflicts. Engineer time spent on logistics, not product.
• Glossary and QA tooling. Keeping vocabulary consistent, catching missing keys before production, validating translations: more tools to build or duct-tape together.
• Distribution. The moment you want to fix without redeploying, you have to run a CDN, caching, versioning, rollback — a project in itself.
• Multi-framework support. A homegrown base built for React doesn’t carry over to mobile or another framework as-is. You rewrite it.
• Production bugs. A missing key or a wrong currency at checkout is a lost conversion and a support ticket. Hard to quantify, painful to absorb.
• Time-to-market. Every new language that takes weeks instead of days is a market a competitor reaches before you.
• Debt and bus factor. The homegrown system ends up understood by one person. The day they leave, the cost spikes.

Putting numbers on it

Let’s model a first year for a multi-language app under active development. Illustrative figures, to adjust:

Line item	Homegrown i18n (yr 1)	Platform (yr 1)
Initial build	5–10 d ($3,000–6,000)	Integration: 1–2 d
Maintenance	1–3 d/mo (~$10,000+)	Included
Workflow + glossary + QA	To build (var.)	Included
CDN distribution / versioning	To build + host	Included
Subscription	—	Known annual cost
Visible year-1 total	~$13,000–20,000+	Integration + subscription

Homegrown isn’t “free”: its cost is simply deferred and diffuse. A platform turns a variable, unpredictable cost (engineer time) into a fixed, predictable one (a subscription), while freeing developers for the product.

A worked example

Take a SaaS going from 1 to 4 languages over 12 months, with a product team tweaking text every week. Homegrown: 8 days to build, then 2 days/month of maintenance and translation logistics, plus a mid-year mini-project to stand up a CDN so you stop redeploying for every fix. You hit 30+ engineering days for the year — the equivalent of one developer tied up for over a month, on plumbing rather than product.

The same year with a platform: 2 days of integration, then most of the translation work carried by non-developers in a dedicated workflow. Engineering cost drops to a handful of days; the rest becomes a predictable subscription. Even if the subscription isn’t zero, the engineer time recovered usually covers it several times over — and that’s before counting the bugs you didn’t ship.

Three common miscalculations

When comparing build and buy, three biases almost always tilt the verdict toward homegrown:

1. Counting only the initial build. It’s the smallest line item. Maintenance and logistics, spread over years, weigh far more.
2. Ignoring opportunity cost. Time spent maintaining homegrown i18n is time not spent on product. That’s not neutral: it’s a feature you didn’t ship.
3. Discounting risk. A localization bug in production, or the departure of the one person who understands the system, are real costs — rare, but expensive. A platform pools them.

When DIY is enough

Fair is fair: DIY is sometimes the right call.

• One or two languages, stable content. If your text barely moves and you’re not adding markets, a simple homegrown t() does the job. Don’t add a platform for the sake of it.
• No translation team. If developers translate it themselves, the workflow adds no value.
• Frozen or internal project. An internal tool with no conversion or growth stakes doesn’t justify the investment.

The rule: if your i18n almost never changes, the hidden cost stays low.

When a platform pays for itself

Conversely, the math flips fast the moment any of these show up:

• several languages and the intent to add more;
• frequent text fixes;
• non-developer translators who need a real workflow;
• multiple frameworks or platforms (web + mobile);
• sensitivity to missing keys in production (e-commerce, checkout);
• a time-to-market that matters for new markets.

In those cases, a platform often repays itself within a few months on recovered engineer time alone — never mind the bugs avoided and the markets reached sooner.

How to decide

A simple three-question grid:

1. Will my i18n change often? If yes, the hidden cost of homegrown climbs.
2. Who translates, and with what tool? If it’s not the developers, a workflow has value.
3. How many markets and frameworks in 12 months? The higher the number, the more a platform pays off.

Answer “rarely / the devs / just one” and stay homegrown. Answer “often / translators / several” and do the math — it nearly always leans the same way.

Do the math

The trap with homegrown i18n isn’t that it’s bad — it’s that it looks free. The cost is just invisible, spread over months of engineer time and a few well-placed bugs. Putting it down on paper is usually enough to settle the question.

That’s Sonenta’s bet: turn that diffuse cost into a predictable one and give developers back to their product. Our pricing page puts a number on the “buy” side; the “build” side already lives in your timesheets. And if the verdict leans toward “buy” while you’re already on i18next, the switch is gentler than you’d think — see migrating from i18next.