You can just build things. But should you? The build vs. buy debate in localization

A group of software developers was asked to make their product available in more languages...

And at first, it worked really well. A few strings go in, translated text comes out, and the natural conclusion is: "We just need to build a simple dashboard to track this, and we're done. Claude can do this overnight!" No new subscription, no procurement, no platform to learn.

Anyone who's spent time with AI coding agents knows how fast you can ship now. It's genuinely possible to build seemingly complex internal tools in an afternoon.

So the question that follows is rational: Why pay for a localization platform when we can build something ourselves? Heck, why pay for any third-party software at all?

👷‍♂️ The appeal of creating your own stuff 🔗

I am not a developer. But I've always liked creating stuff. It all started with me learning Photoshop in the 6th grade of elementary school. Then I started building my first websites in Microsoft FrontPage (IYKYK). Then I learned HTML and CSS (by reading actual books!).

Afterward, I reached the golden age of Bootstrap, and then I finally decided to use WordPress for my clients (still not sure if that was a good idea, but most of the sites still work today). I was using all of these things other people have built to make my life easier, enabling me to create more cool stuff with less time spent on boilerplates.

And so I build things with Claude myself today as part of my work — pricing calculators, API connectors and automations, HTML prototypes to visualize ideas... Things that would require a dev ticket a few years ago, I can now ship myself. But I've always been deliberate about where I stop.

I'd never want to be the one building internal tools available to others in the company, because then I'd have to maintain them based on someone else's needs. I don't want to run another product for end users on top of my actual job.

Most teams starting a DIY localization setup don't have a clear idea of what they are getting themselves into when they build their own tools instead of looking for solutions built and maintained by others.

Yeah, I know, some reports suggest that 35% of US companies have replaced SaaS tools with custom solutions, and 78% expect to build more of their own tools in 2026.

And every time we look for a new tool, I hear colleagues claim: "We can build our own in an afternoon!" Yeah, I know we can, but should we? It was always possible to build our own tools. And the coding agents give us all the power to build more and faster.

So, where is the line between build vs. buy in the age of AI?

🔩 Why the DIY route feels solved today 🔗

The first version is always a breeze. You export some strings, run them through an AI, and the output looks good enough. The casino paid out.

That's not a metaphor I'm using loosely. Working with AI tools has a distinct emotional rhythm — the buildup while it processes, the anticipation before you see the result, the spike when it works. It's engaging precisely because you don't always know if the output will be exactly right, or subtly wrong in a way that won't surface until later. At the prototype stage, it works. You ship it.

What usually happens after the proof of concept is much simpler than a deliberate architecture decision. You need an interface that lets your team edit the strings if the AI does a bad job, so you build it. And now you have a translation tool for your apps. Now marketing wants to localize the website, so you add an integration. Boom, done.

The output gets reviewed by someone on the team and imported back into the product and website. It works, so the conclusion becomes, "we don't need a full localization system." Or, more confidently, "we can just build it ourselves as we go."

Our colleagues spoke with many people at Digifest who were doing exactly that. Excel plus DeepL was common. ChatGPT for translation was common. Custom wrappers, too. Most of them hadn't noticed yet that they were rebuilding localization infrastructure that other companies had spent years stabilizing... just without the reliable parts.

⚠️ Where the prototype stops working 🔗

The first cracks tend to be technical. First, placeholders get corrupted.

Then, plural rules that work fine for English break in Czech, then break differently in Polish, and Arabic is another world entirely.

But the deeper issue isn't technical edge cases. It's quality, context, and consistency.

A word like "Save" seems harmless until it appears dozens of times across your product in different contexts. Without duplicate resolution and terminology control, you end up translating the same thing multiple times: inconsistently, expensively, and incorrectly.

A fluent translation that ignores context looks fine until it's in front of a user who actually speaks that language. AI output can look polished and still be wrong in domain-specific or contextual situations: fluency is not the same thing as accuracy, and in localization, one without the other causes real damage.

By the time the problem surfaces, it doesn't look like a translation problem. The CEO sees revenue dropping in a specific market. Marketing notices conversions are down, and bounce rates are rising. Support gets more tickets from those users. Nobody immediately connects it to a string that got mistranslated two months ago. Each layer of the company sees a different symptom, and the cause stays hidden until someone traces it back. By then, it's already spread.

AI output can look polished and still be wrong in domain-specific or contextual situations. By the time quality and consistency problems surface, the damage is already done

And when it comes to "AI can translate this, we just make an API call, and it's done!" How do you know what to put in the prompt? You are optimizing prompts, burning tokens, and building additional features. ChatGPT doesn't remember how you translated a term last week. So you start building a terminology base for your prompts. Then you need to verify the AI actually used those terms. Then you need someone to check that. "Oh yeah, just one more iteration, boss! We are close to solving it."

Context in localization isn't optional. It includes screenshots, glossary terms, style guides, character limits, tone rules, and previously approved translations.

"Yes, I am on it, I can do this!" Yes, you can. But once you need all of those consistently, you're not solving a translation problem anymore. You're building infrastructure.

And before you know it, one afternoon turns into months of development and then years of upkeep. You've built a context management workflow, a review workflow, and a validation workflow on top of your translation and i18n workflows. All from scratch. And the thing that seemed simple now has layers you didn't plan for.

So you just lost weeks reinventing the wheel. And it's your wheel: every time it breaks, you or your developers have to stop what they're doing and fix it.

🧐 What it actually costs 🔗

We all know context is the king of localization. But there is also another type of context. That one lives in your team's heads, and switching context frequently will kill your productivity. You are going to spend more and more time on building internal tools instead of focusing on what matters. That precious time should be spent solving problems and improving the experience for your customers.

In the end, the tooling might work well enough that nobody replaces it, but it creates constant friction. Every new market means rediscovering which edge cases your setup doesn't handle. Every new team member needs to learn how the system works, so now you are writing documentation as well. And the time is ticking. And the context keeps switching. 🤷

That's easy to overlook when you're weighing the options. But engineering time alone adds up fast. An engineer spending five hours a week on internal tooling at €75–100 per hour is already €1,000–2,000 a month before you count bugs and delays. And I am being optimistic here.

In the end, you might save some money on the license fees. But you give yourself and your developers extra work. And remember, the work is never just “the work”. There are things you cannot even estimate for, and they grow into another project you have to manage. Dave Stewart put it in a pretty fitting infographic. And while it is mostly about agency type of work, it holds true for pretty much any kind of project:

So the developer who tells you they can "prompt it in an afternoon" is wrong. It will eat their time and your budget. Of course, if you are paying hundreds of thousands of dollars a year for a tool that one developer could maintain with AI agents writing the code, go ahead and kill the subscription and devote your own resources to solving it. But I don't think this is true for 99% of the subscriptions you (or we) pay for.

So, are you actually going to save money?

➡️ What you're actually buying when buying software 🔗

With some solutions (and I dare to say, with Localazy especially), you are not buying "Software as a Service" but "Software AND a Service." So when I argue against self-built solutions, I don't lead with features. Everyone can build features.

What I tell people is that buying software means gaining access to the accumulated knowledge of how this problem works. When you arrive at an edge case you didn't anticipate, we've probably already built something to handle it. You don't know what you don't know.

We've helped hundreds of teams work through these exact issues over the years we've been in this business. We also have a team of native speakers just a button away to review your strings, whether they were translated by AI or not.

So you are not buying a fancy UI; you are buying access to someone who already knows where localization tends to break and who devotes all their working hours to solving their customers' localization needs more efficiently than they can themselves. It's really not just about building a tool that moves strings around.

It's the expertise gap you can close only by hitting walls you didn't know existed. The plural rules, the placeholder edge cases, the terminology drift, the review workflow... You rediscover each one in production, usually under pressure. A proper TMS comes with that knowledge built in, at a fraction of the price.

Most companies that reach out to us aren't looking to replace a localization department. They don't have one. They're a product team that started shipping to new markets and realized pretty quickly there's more to it than running strings through an AI. They didn't want to become localization experts. They just wanted their product to work in other languages, and work well enough that users in those markets actually stick around.

There's a type of expertise you only acquire by hitting walls you didn't know existed. A TMS comes with that knowledge built in. If you build your own solution, you have to account with that and the engineering time you'll invest in it

But this whole discourse isn't localization-specific at all. Sanity wrote about the same pattern in the CMS world after a high-profile customer migrated off their platform to markdown files and custom tooling.

Their take: "You can delete the CMS, but you can't delete the need to manage assets, control who can publish what, track changes, and structure your content." Give it six months, and the bespoke tooling grows. Edge cases multiply. Someone needs a feature that wasn't in scope. Same story in a different category.

💬 Ego-prompting is bad for you 🔗

There's another version of this conversation, which, to be fair, we've had more often than we'd like lately. It's with teams already using Localazy who are wondering whether to replace it with something they built themselves now that AI makes that feel more viable.

If that's you, you already know what localization involves. You've already configured your workflows, built up translation memory, and set up your integrations.

The question isn't whether AI makes translation easier. It does. We spend a lot of time on research to get it right as we continue improving Localazy AI (in fact, our dev David has been writing extensively about it). When it comes to AI localization, you will have to write a prompt. But how are you supposed to know exactly what to write in the prompt? Spoiler: "Translate X to Y language" won't work. At Localazy, we are optimizing this all the time, and our AI isn’t just a single prompt: it’s a multi-step reasoning process of which the translation itself is only a small part.

So, it might be worth thinking about what you'd actually be replacing: everything you've already figured out the hard way, every new edge case your custom setup would introduce, and every improvement you won't get because you're no longer subscribed to a product whose entire purpose is to stay ahead of this problem for you.

Going the DIY route doesn't make the problem go away. It just puts you back in the position of having to solve it yourself. That's exactly the point: our team's energy belongs to the product we build for you. We are not vibe-coding a new CRM now just because we can. We are making Localazy better for our clients. So my advice is to kill your ego. You don't have to prove to anyone that you can solve it in a few prompts to save a few hundred dollars per month.

Going DIY doesn't eliminate the localization problem. It just puts you in the position of solving the problem yourself. You have to choose if putting your energy there is worth it

You can build it. Building it is the easy part. Being the person responsible for maintaining it at scale, while the product keeps changing and the edge cases keep accumulating, is a different commitment entirely.

The human species has evolved over thousands of years and has naturally discovered the miracle of the division of labor. Why go against the evolution now by doing everything yourself?

✔️ Conclusion 🔗

Over the past few months, I have had conversations about build vs. buy more often than I would like. Marta from our marketing team kept asking me about this article every two weeks and even hired a writer to help me kick things off.

It turned from an interview into an essay. Then it was rewritten about four times, because each time I talked about it with someone else, I had a new perspective on the problem.

So please, let me know what you think about this in the comments. I am genuinely curious about others' opinions. Only time will tell if I was right.