The Buy vs. Build Trap — Why 80% of Companies Choose Wrong on Translation

A Fortune 50 company’s SVP explained the problem clearly: “We have 300,000 employees. Now we suddenly have 300,000 voices. How do we make sure the content that’s translated into local languages actually matches our brand?”

That question reveals why most companies are making a mistake in translation. They’re either plugging in an off-the-shelf API (GPT-4, Vertex AI, Bedrock) and calling it solved, or they’re building custom infrastructure in-house. Olga Beregovaya, VP of AI at Smartling, has watched this play out 100 times over: one approach is almost always wrong.

“When you think about it, there are so many dimensions,” she explains. And that’s the trap. Translation looks simple until you actually have to do it at scale for a global brand. That’s when the hidden costs materialize.

The API Plug-In Delusion

The easiest path looks obvious: use GPT-4 or Claude via an API. It works. It’s cheap. Ship it.

For some use cases, this actually works fine. “There are absolutely use cases where you can plug in GPT and call it a day,” Olga acknowledges. User-generated content, quick translations that won’t affect brand reputation, unvetted content that’s already risky—fine. One engineer spends four hours integrating the API and you’re done.

But here’s the problem: the moment you care about output quality, this breaks down.

The model itself is a commodity. It doesn’t understand your brand voice. It doesn’t know your product terminology. It hallucinates in languages with little training data. And most importantly, you have no visibility into what it generates across thousands of pages and hundreds of languages.

“Plugging in an API and calling it a day might not be the way to go,” Olga says flatly. She’s seen companies do this, get burned, then scramble to find a different solution.

The Build-It-In-House Trap

So companies go the other direction: build custom translation infrastructure. This feels like control. It feels like you own the solution. And it is, technically—until you count the actual cost.

What does in-house translation require? Start with the basics:

Hallucination mitigation. You need to detect when the model generates plausible-sounding nonsense. That requires semantic similarity checking, fact-verification pipelines, external validation. It’s solvable but not trivial. Olga mentions the common approach: “You might find yourself plugging one model on top of another model to see what that first model is doing.”

Quality monitoring. Once content is published across multiple languages in multiple markets, you need to know if it’s actually good. Build: logging, monitoring dashboards, error tracking, user feedback loops. This is ongoing infrastructure, not a one-time build.

Data governance. Can your engineering team handle the MLOps of managing translation data? Keeping it secure, preventing data leakage to model providers, managing fine-tuning datasets, versioning models, rolling back broken versions? This is where hidden complexity explodes.

Latency engineering. Longer prompts = slower responses. You want to give the model context (product docs, brand guidelines, examples), but adding context slows everything down. So you need to solve: caching, prompt optimization, vector databases, maybe even quantized models for speed. Every added feature multiplies complexity.

Brand consistency at scale. The Fortune 50 problem: when your 300,000 employees are generating content in 50 languages, the tone is inconsistent. Some locations interpret “friendly brand voice” as casual; others interpret it as professional. Without fine-tuning and guardrails, the model will reflect that inconsistency.

Add all of this up, and suddenly your “simple translation API integration” is a full platform engineering effort. Olga walks through the math: “You need this much head count and you’re assuming this many risks.”

What Actually Costs Money

Here’s where Olga breaks it down concretely. When you run the spreadsheet on build vs. buy, the costs look like this:

Build cost = head count + hidden risk.

You’ll need: ML engineers to fine-tune models, data engineers to manage datasets, DevOps to handle infrastructure, QA specialists to catch hallucinations, linguists to validate output, and probably a product manager to coordinate it all. For a mid-market company, that’s 5-8 people at six-figure salaries, plus infra costs. Call it $1.5M to $2M per year, forever.

And you’re assuming the risks: if the model breaks, it’s your team’s problem to fix. If hallucinations slip through, your company’s reputation suffers. If a language feature breaks, you’ve got to debug it while customers are affected.

Buy cost = licensing + limited engineering.

You’re paying a vendor (Smartling, Anthropic’s translation service, another platform) a percentage of your localization spend or a flat fee. A company doing $2M in translation annually might pay 20-30% for the platform. That’s $400K-$600K per year—but that includes hallucination mitigation, quality monitoring, brand guardrails, data security, and 24/7 engineering support when something breaks. You still have some internal resources, but it’s 1-2 people managing the vendor relationship, not 8 people building infrastructure.

The math is usually decisive: “Buy would probably cover 80% of cases,” Olga says.

But then she adds the caveat that matters: “There are still just 20% of cases where build or just plug-in is legit.”

When Build Actually Makes Sense

So when do you build?

When you have proprietary translation requirements no vendor solves. If you’re a company where translation is a competitive moat (some enterprise SaaS companies, some healthcare software), and you have bleeding-edge requirements that no platform vendor has built yet, maybe you build. But be honest: is this really your moat, or do you just think it is?

When your volume is so enormous that platform fees exceed the cost of your engineering. If you’re Google or Meta and doing billions of translation units per year, the per-unit cost of a platform vendor might exceed the marginal cost of your own infrastructure. The crossover point is probably somewhere around $50M+ annual localization spend.

When you’re in a heavily regulated domain where you need full audit trails and can’t trust a vendor. Financial services, healthcare, defense—these have requirements around data sovereignty and audit that might push you toward build. Even then, you might buy a solution and build compliance infrastructure on top.

When you’re willing to accept lower quality to save money. Some companies genuinely don’t care about brand consistency across 50 countries. They just need content that’s “good enough” to avoid major complaints. Then API plug-in works fine. But admit that’s your choice.

That’s it. For almost everyone else? Buy.

The Real Cost of Getting It Wrong

Here’s what happens when companies get it wrong:

Bought but doesn’t own it: A company licenses a platform but doesn’t integrate it properly. They think they bought a solution but actually they bought a tool they don’t know how to use. Translation quality stays poor.

Built but never maintains it: A company builds internal infrastructure, then the founding engineer who owned it leaves. Suddenly no one understands the system. It breaks when the OpenAI API changes. Hallucination detection stops working. Quality degrades over months while leadership doesn’t realize.

Plugged in and released too soon: A company puts GPT-4 on top of their user-generated content without quality checks. Users generate content in three languages. The model translates all of it. Some of the translations are wrong in ways that break the app, introduce legal risk, or embarrass the brand. Now they’re in crisis mode and have to pay expensive contractors to audit everything.

The cost of getting it wrong isn’t the licensing fee or the engineering team. It’s the damage to reputation, the customer churn, the compliance risk when a hallucination violates regulations.

The Framework to Decide

Olga’s heuristic: ask yourself these questions.

1. Is translation a competitive advantage for my company? If yes, build. If no, move to question 2.

2. Do I have more than $50M annual translation spend, and is my organization large enough to justify a specialized translation team? If yes, consider building. If no, move to question 3.

3. Do I need guarantees about data security, compliance auditing, and full control over how my content is processed? If yes, build or hybrid. If no, move to question 4.

4. Am I willing to accept some hallucinations and brand inconsistency in exchange for lower cost? If yes, plug in API. If no, buy a platform.

If you answered no to all four: you’re a buyer. Most companies are.

The trick is admitting it. “I would say it’s a combination of trust, credibility and safety and quite often cost,” Olga explains. You’re not just buying a tool. You’re buying 15 years of translation domain expertise, 1,000+ integrations with content management systems, fine-tuned models for 50 languages, and round-the-clock engineering support so you can sleep at night.

That’s worth paying for. Unless it isn’t.

FAQ

Can we start with an API and move to a platform later?

Technically yes, but it’s expensive and slow. When you’re using GPT-4 directly, you’re building translation workflows around that API (caching, error handling, prompt engineering). When you switch to a platform, you’re ripping out months of work and rebuilding. Better to pick the right solution from the start.

What’s a reasonable budget for a translation platform?

Depends on volume. For a mid-market company (50-100 languages, $1-2M localization spend annually), expect 20-30% of localization spend for a platform, maybe $200K-$600K per year. For enterprise (global company with extensive localization), it might be lower percentage because of volume discounts.

Should we build quality assurance on top of whatever solution we choose?

Yes. Whether you buy a platform or build in-house, you need human review for brand-critical content, especially in high-stakes domains (healthcare, legal, financial). QA isn’t optional—it’s a cost of responsible localization.

What’s the difference between a “translation platform” and just using an API?

A platform includes: fine-tuned models for your languages, hallucination detection, brand voice guardrails, QA workflow integration, data security/compliance, monitoring dashboards, and vendor support. An API is just the model—you build everything else yourself.

Can we really plug in GPT-4 and use it for production translation?

For non-critical content, yes. For user-generated content where accuracy doesn’t carry brand risk, yes. For anything that touches your brand voice or could cause legal/compliance issues, you need additional quality infrastructure. At that point, you’re building the platform anyway.

What happens if the hallucination rate is unacceptable even with a platform?

You need to fine-tune the model on your data, implement retrieval-augmented generation (RAG) with your verified content, or add human review. All of these increase cost. If your hallucination tolerance is very low, you might move toward majority human translation with AI assistance, rather than AI-first translation with human review.

How do we know if a vendor’s quality is actually good?

Ask for a pilot with your actual content in your actual languages. Run blind evaluation where you compare vendor output to human-translated benchmarks. Check their hallucination mitigation approach—is it semantic similarity? Fact-checking? Human review? Their answer tells you how seriously they take quality.

What if we’re in a regulated industry like healthcare or finance?

Buy a solution built for regulated industries. These vendors understand compliance requirements, audit logging, data residency, and liability concerns. Trying to build this yourself is more expensive and riskier than buying a specialized solution.

Can we negotiate platform fees down?

Often. Volume discounts exist. Multi-year commitments get discounts. If you’re a large enterprise, you can probably negotiate. But don’t negotiate so hard that the vendor can’t invest in improving their service.

What if our translation needs are truly unique?

Be honest: are they unique, or just different from competitors? If you’re using translated content the same way as your competitors (website, docs, support), your needs aren’t unique. If you’re doing something genuinely novel (like real-time multilingual collaborative editing), then maybe you build. But most companies think they’re unique and aren’t.