Last year a lot of the people and companies I talk to tried building their own “translation platform”. Most of them have stopped and realized it’s not the right strategy.
I’m sure for some companies it makes sense. But for a lot of them it really doesn’t. From what I see, even big AI companies buy their translation tools and services from translation/platform companies. You would think they have the tokens to build their own, but they choose to just buy one.
I understand why people started doing it. Some of these platforms are super expensive, and with claude or codex, you can get a working MVP quite fast.
AI coding is great, but for larger systems it might not be as cheap as you think. Time and tokens are going to be the most expensive part here.
So here are the three options I think we all have.
Option 1: Build your own
Pros:
You can create something that is custom-made and fits your organization. You stop paying for features you never use.
A simple MVP can be created super fast now.
Cons:
It is not a weekend project. You need far more than you expect: vendor management, project management, connectors, a translation editor and a long list of translation features you don’t even know your PMs and translators need.
In its first year it will not be as good as a proper TMS.
Somebody has to maintain it for years.
The companies that struggle the most usually have good engineers, but not much translation experience. They assumed connecting AI was the whole job. It was just the beginning, while their local teams weren’t happy with the quality, and AI translation on its own wasn’t good enough.
But the biggest cost, in my opinion, is that it’s a distraction. You spend a year on something that, even if it works, leaves you where you started: with a translation platform that you already had anyway. Your processes haven’t changed, and that’s where you should have looked first. But you were distracted by a shiny new thing.
Who should build their own? Start with the reason (or “Start with Why”, if you will :) ). Build when there is something missing that you need day to day. If you can’t name that thing, don’t build.
Then the team. You need technical people who understand what they are replacing and what they are trying to improve, who know translation, and who plan to look after it for years. Those teams exist, but might be hard to find.
Option 2: Keep the translation platform you are already paying for and automate the rest
Pros:
You build automation that helps you run production and saves you way more time.
If it stops being useful over time, it’s not a problem. You can just stop using it whenever you want.
Cons:
You keep paying the TMS subscription.
You are limited by what the platform lets you do from the outside.
One example. After translators deliver, somebody should check the files: numbers, placeholders, glossary terms. In practice a PM did it by hand for every language, or it was skipped. So I built a check that runs on its own after every delivery, runs around forty checks and messages the team only when it finds something serious. Nobody has to remember to do it.
Other automation you could build or set up:
the regular checks a project manager does by hand
task creation
reporting/data
QA and testing
connecting your systems
i18n work
context for translation
Option 3: Switch to another translation platform, then automate
Pros:
Another platform may fit your stack better and/or cost less.
Moving the data (your TMs, glossaries, etc.) is easier than it used to be, thanks to AI and better infrastructure.
Cons:
It can still take anywhere from one month to a few months, depending on company size and whether you also have to develop new connectors, etc.
Moving data isn’t the issue. Onboarding new vendor and people is, and no tool speeds that up much.
If your processes aren’t fixed, a new platform is not going to fix them for you.
What I’d do
Personally, I think it’s better to buy a translation platform that suits you best (options 2 and 3) and automate the rest.
With coding agents, building your own platform is tempting, but in my opinion focusing on internationalization, context for translators, data and automation is the better choice right now. Sure, that might change in a couple of years, and it really depends on the company.
It’s not only about translation. You have the same choice for a CRM, an ERP, or any other system your company has. Build around it first.
If something in your localization team gets done by hand every week, start there.
This is the work I do. If you want a second pair of eyes on your setup: hello@sebastiandziecielski.com