Build or buy? You’re probably asking the wrong question

Somewhere in your organization, someone has already built a translation prototype. An engineer ran some content through an LLM over a weekend, the output looked surprisingly fluent, and now there’s a working demo making the rounds. Maybe a VP turned to their tech team and said “isn’t there a faster way to do this?” Maybe an enthusiastic developer knocked something together in a sprint. Either way, it works. And now you’re wondering whether you even need a translation platform at all.

The broader build-versus-buy debate is one I’ve explored before in Forbes. The question is often framed as a technology decision. In practice, it is usually a question of where your organization wants to invest its time, expertise, and long-term operational ownership.

So let me say something that might surprise you coming from a platform vendor. It would be crazy if your teams weren’t building things. Given how much easier it’s become to build, it would be genuinely strange if smart engineers weren’t experimenting. The question isn’t whether they should build. It’s what they should build.

The framing I use with every customer who asks is simple. Buy the spine, build on the edge. Buy infrastructure, then build the custom pieces that genuinely differentiate your business. Specialist workflows, proprietary data models, unique content pipelines. That’s where your engineers create real value. Not rebuilding plumbing that already exists in production-grade form.

For about 90% of businesses, this hybrid approach makes a ton of sense. But to understand why, you need to see what happens when the prototype meets reality.

What the demo doesn’t show you

Phase one is always seductive. Within days you’ve scaled a couple of languages, handled a few content types, built some basic workflow. The engineer who built it is feeling good. The exec who sponsored it is feeling vindicated.

Phase two is where it unravels. Scale that to 10 or more languages and multiple content types, and you start to notice strange behaviors. AI is fluent, and that fluency is the trap. A model can generate a plausible translation while simultaneously using the wrong brand terminology, ignoring a legal requirement, or mistranslating a term that matters enormously in a specific market. At low volume, you don’t notice. At production scale, it compounds.

Here’s the part that catches people off guard. Success makes it worse. If the MVP works, adoption follows. Adoption brings feature requests. That enthusiastic engineer who built the prototype in three days is now bogged down in bugs, edge cases, and an ever-growing list of requests from teams who depend on something never designed for production.

One of our customers put it perfectly.

“Every hackathon, engineers decide they can build their own translation engine. Every time we try, and every time we fall back to buying.”

The cost you’re not counting

The most common objection I hear is that building feels free. Your localization team borrows a few engineers from another department; they’re not paying for them directly, so it doesn’t show up as a line item. But someone is paying those salaries. Surface the real cost to whoever holds the budget, and the conversation changes quickly.

If you’re serious about building, you need three to five people across product, engineering, QA, and management. At fully burdened cost, that’s $150,000 to $200,000 per person depending on geography. Add security, compliance, release management, infrastructure. You’re looking at $450,000 to over $1 million annually, before you account for the feature requests that come with success.

Compare that to a platform. We have around 130 to 140 people across engineering, product, design and QA, and we spread that investment across nearly 4,000 customers. Our average enterprise customer pays us less than the cost of a single engineer. It is simply not possible for a small internal team to replicate what a dedicated platform delivers by distributing R&D across thousands.

There’s also a governance question that doesn’t get asked often enough. You wouldn’t let an engineer build your sales process or legal workflows without input from the people who understand those domains. So why would you let them build a translation pipeline that touches your brand, your legal compliance, and your customer experience?

The “just call an API” approach skips the hard parts. Context management, terminology governance, quality infrastructure, routing logic for human review, role-based access control, audit trails. AI is the engine, but you still need the steering wheel, the chassis, and the airbags.

The thing you can’t replicate alone

When you build from scratch, you’re committing to building and maintaining every integration yourself. Your CMS connector, your design tool integration, your marketing automation link, your code repository hook. Each one needs building, testing, and maintaining as those upstream systems change. That’s not a one-time project; it’s a permanent expansion of scope.

When you build on a platform, you inherit an ecosystem. In our case, that’s a growing network of technology partners who build and maintain solutions you can plug in without writing a line of code. Need to swap out an AI engine as models improve? You can bring your own, or choose from what the ecosystem offers. You’re building on top of an open platform where third parties compete to make your setup better.

A DIY approach locks you into whatever your team builds today, and the technology landscape is moving so fast that today’s decisions can look outdated within months. An ecosystem evolves continuously. Partners release improvements, new integrations appear, and the platform advances without your engineering team lifting a finger.

Five questions to ask before you commit

If you’re evaluating a build approach, or if someone on your team has already started one, these are the questions that tell you whether the demo can scale:

1. What happens when the person who built it leaves? Most internal translation projects depend on one or two people who combine AI knowledge, domain expertise, and company context. That combination is rare. If they move on, the project typically collapses.
2. Have you costed the full team, not just the prototype? A working demo needs one engineer for a week. A production system needs three to five people indefinitely, plus the feature requests, maintenance, and support that come with adoption.
3. Does the person paying the engineering salaries know where those engineers are spending their time? Borrowed engineers feel free to the team using them. They’re not free to the organization.
4. What’s your plan for 30 languages, not 3? The long tail of low-resource languages is where DIY breaks down. Less training data, less accuracy, more edge cases. What works beautifully for English to Spanish doesn’t automatically scale to Turkish, Thai, or Vietnamese.
5. Are your best engineers working on your core product or on translation plumbing? Every sprint on translation infrastructure is a sprint not spent on the features that drive your roadmap and revenue.

The bottom line

We love builders. We’re builders. The goal isn’t to stop people building. It’s to redirect that energy to where it creates real value. Buy the infrastructure, build the differentiation. Skip the painful second phase where the promising prototype hits production reality, and get production-grade foundations from day one while keeping the freedom to innovate on the edges.

The smart ones are building on platforms, not from scratch.