A response to Nimdzi’s The Build-or-Buy Trap of Language AI Platforms.
I’ve spent over 20 years in the translation and localization industry, and traditionally, no matter who you worked for, you knew who your competitors were. If you review articles from pre-2023, you’ll see that in a commoditized market, the top recommendation was always specialization. Three years fast forward, and the industry’s feed is full of overnight AI experts, software developers, localization masterminds – most of whom have never shipped a pipeline that survives contact with a real enterprise workflow. The credibility built over decades got drowned out, not replaced, and still, most companies have only gained limited adoption of AI. If the market is this crowded with experts, why are we only here?
Nimdzi names the way out of this as a third alternative: build on top, instead of build or buy. I agree with the diagnosis. What I don’t see enough of is anyone showing what building on top actually looks like in production, as opposed to putting the phrase on a homepage. Plenty of platforms have started calling themselves “the layer to build on” in the last six months. Few of them were architected around that promise before the phrase existed. We were, seven years ago, before we had a name for it – back then we called it vendor-agnostic middleware, because the problem we set out to solve was the multi-vendor environment, which is the norm rather than the exception in acquisition-heavy enterprises and in any LSP, since both end up working with clients or business units running on entirely different tech stacks.
With the external push from decision-makers outside the industry especially at enterprise organizations to implement AI, companies are often trying to reinvent things from the ground-up. When I go to enterprise meetings, I often hear two things:
- We can’t really clean up the mess of different flows, so we’re building another system to migrate everything to.
- We’ve run a PoC with a TMS provider.
The “other system” is often developed by engineers, who are also including AI features in it. This is what should drive AI-only workflows. The TMS provider PoC is driving the human-assisted workflow. However, the two hardly meet, and the quality management program definitely should depend on the technology selected – not only in current evaluations but also evaluations after model or algorithm update. So if you are using two AI policies, you need two quality programs.
Previously, my understanding was that where a company cannot really tolerate variation is reporting. KPIs are KPIs no matter the work streams. The numbers that fuel reports must come from someone: either the organization produces it, or they trust their vendors to deliver the figures. But the numbers must be meaningful and comparable. Comparability comes from normalization.
Recently I realized that unified AI strategies can also be developed by organizations, because what works for them depends very much on their content, context and their understanding of quality. Some can only use certain models, others are not restricted. The good news about localization AI is that text-based localization is very simple to embed: you take a bunch of strings with context data and you receive the same amount of strings. The applicability, the plumbing differs between TMSes and other tools, but the LLM and MT APIs are both very simple.
After all the recent turmoil, I was very pleased to read Nimdzi’s report where they state that reinventing the wheel is not innovation, and build or buy has a third alternative, to build on top. At BeLazy, we’ve been building a platform from day one that people can build on, exchange any component, and still remain operational. This is what Nimdzi calls “optionality,” and they put it like this:
“True optionality requires distinguishing between […] layers, ensuring that the core technological foundation has the agility to support AI model updates and upgrades rather than forcing a complete system overhaul.”
Let’s be plain about what that means in practice, before I get into the reasons list. An enterprise typically has one or more CMSes but no BMS (Business Management System). An LSP typically has a BMS but no CMS. Both of them have a TMS, often more than one. We think all three of these areas, and how AI fits into each of them, matter a great deal – but that doesn’t mean every organization owns all three systems. It means every organization has the underlying need: project tracking, vendor assignment, vendor evaluation, revenue and cost tracking, reporting, content management, whether or not there’s a named system for it, and whether or not anyone in the organization calls it a BMS or a CMS. BeLazy connects to more than one TMS at a time, to a single BMS, and to your CMSes, wherever these exist in your stack, and it doesn’t ask you to replace any of them. Where there’s a gap – most often on the BMS side – enterprises needed this kind of reporting and vendor management all along, they just didn’t have a proper tool for it and kept it running on manually maintained Google Sheets, or JIRA or Asana tickets, instead. The AI era is what made that gap impossible to ignore. This is exactly where the project management Google Sheet can stand onstand in on its own, with no BMS behind it at all.
Where a BMS already exists, the Google Sheet complements it instead, adding automation and reporting flexibility rather than replacing anything. Google Sheets is what we’ve built and validated so far; if enough enterprises tell us they’d rather have this running in Excel365 instead, that’s a natural next tracker for us to build. We sit on top as the orchestration layer, needing only a single TMS as the bare minimum to operate, and we cover all the standard, crucial capabilities ourselves in a simple way – but wherever there’s a better or legacy system already doing that job, we orchestrate with it rather than replace it, and we make these systems talk to each other and to whichever AI you’re using, in whatever combination you have today or decide to have tomorrow. Nimdzi itself points at this end state elsewhere in the report, when it describes the “headless TMS”:
“An ultimate goal might be the ‘headless TMS’ accessible via API connections in any user interface with pay-for-what-you-use features (acknowledging that, in this case, the TMS label is no longer fitting the bill).”
In this article my goal is to present how BeLazy’s design principles and current realities support the reasons why we’re an ideal partner to build on.
The building reasons
The Nimdzi report identifies the following reasons as the main drivers why organizations choose to build their own language technology platform.
Costs and TCO
Let’s start with the big one. I just had a conversation where I made the claim that ROI should be replaced by TCO in new sales conversations, simply because ROI is so unpredictable with the change of LLM models that it’s better to focus on two things: how the “plumbing costs” are kept predictable, and how the usage costs are minimized. As of today, nobody knows whether translators or localization managers will be replaced by AI or not.
Ben Hylak made a very important observation at the AI Think Tank conference, namely that big tech has been focusing on solving the coding problem, because it’s a higher-value problem to solve than solving the language problem. If they decide it’s time to move on to the language problem, they’ll have the means and the bandwidth to solve it. Whether we accept this observation-prediction or not, we can’t debate that in a few years there’ll be more clarity around this. Until then the ROI of AI is something which is not as easy to calculate as that of the fuzzy matches was.
Let’s look first at the plumbing (system) costs.
Many organizations are not sensitive to AI costs, and are willing to replace software that costs less than half an FTE with self-built capabilities. AI costs are however very unpredictable, as Nimdzi puts it:
“CFOs and financial controlling teams track costs based on historical patterns and robust forecasting. However, none of the AI-related costs have the predictability to back estimations provided by engineering teams (and AI token costs are shooting through the roof by public accounts). The need for expert input (from language technology, not just machine learning experts) is greater than ever: they must validate or scrutinize the often underestimated initial engineering costs to get to a more complete total cost of ownership (TCO) model.”
Spending funds on “reinventing existing, algorithmic plumbing with AI” is a strategic distraction,” and “re-creating solved problems often leads to operational fragility and missed innovation opportunities.”
Another important finding is that in an organization whose primary mission is not software development, there is the fallacy of not understanding processes deeply. “Needs are not static, often not known/voiced, and so last-mile is down-prioritized.” This is where the token burning starts – making up for forgotten requirements, small but important aspects that can make or break the success of a system. The empowerment of the common worker by AI led to the dilution of the age-old truth: “Do not reinvent the wheel.”
The other significant part is relating to the usage of AI not to create a system but to process your content. At BeLazy for example, by allowing different content to be routed to different TMSes, by allowing the use of a customer’s own AI, by allowing content to go automatically into BMSes and at the same time sharing all project information in a Google Sheet with the options to assign and monitor via this Google Sheet, by allowing to automate systems without API costs, we are reducing the unnecessary costs:
- You can save the cost of pushing words that you only need to machine translate through expensive TMSes.
- The cost of TMS vendor-owned AI can be replaced by the cost of user-owned and -optimized AI.
- You can save the one-off cost of certain APIs.
- Not everybody that needs a BMS for reporting needs a BMS license.
The out-of-the-box saving potential of BeLazy, depending on the customer’s stack, can easily exceed its license cost – and its automation-oriented ROI is the cherry on top at no additional cost.
Integration with internal/legacy systems
While some legacy systems are content/project sources, others are used for business management capabilities. For example, you may have an internally developed product information management system, and you may use Asana or JIRA to record the progress of each subcontracted project.
If the integration is with a system where content originates from, the BeLazy project ingestion API offers unparalleled simplicity, equal to the simplicity of the LSP APIs (as opposed to the higher complexity of TMS/BMS APIs).
Three calls to create a project:
- Upload the file
- assign it to a workspace to keep track of them
- and create the project with all the metadata information
A webhook calls back, telling you when something is ready, and you just fetch the files and indicate that the project can be closed. It’s as simple as this, and it works for 100% of the projects we have seen earlier. If it is not a CMS but a legacy TMS, the newly added linguist reassignment and job closing capabilities also support that. You can use this API to build connections that are on feature parity with BeLazy’s own-developed connectors. The big benefit is that a CMS-savvy developer does not need to know anything at all about translation management – no project templates, no rules, not even TMS selection. That is all configured on the UI during mapping. This enables them to get the integration done in a day or two, or even faster with AI.
If you want to use Asana or JIRA to track status, you will find all information on the Google Sheet to start from. The complex work of connecting any TMS – BMS combination to such cards is reduced to a simple Google Apps Script to Asana/JIRA automation, regardless of the source systems. The information is presented in the way you want due to the fact that the UI-oriented value mapping controls what information appears in the sheet – you can freely bundle projects of a day per product line together, or you can keep track of each file, you decide.
And if the configuration of BeLazy is not enough, API calls allow you to change the metadata description of the origin data, or update the BMS project in case you are using a BMS system such as Plunet, XTRF, Protemos, or if you happen to have your own system that communicates with BeLazy through the custom BMS API. And did we mention that the Google Sheet records and presents every piece of custom metadata that you specified in the content connection?
There’s no limitation on what you can represent – just imagine how valuable the end-to-end retaining of custom metadata is when providing reports!
Need for customization
We covered part of this in the previous claim. You can update project metadata that you base all your later decisions on. You can extend the BMS project descriptions. But that is not enough.
Webhooks fire on every single important action – like when a project is created, when a vendor is assigned, when new projects appear, when a project or a workflow step is closed, when an XLIFF is downloaded for processing, just to name a few. All of these events also make it to an activity log for later troubleshooting. These events allow you to respond to a webhook – using tools like Make.com or n8n or Google Apps Script – but also allow you to execute code: LLM-written Javascript. The Google Sheet integration also enables you to run Google Apps Script which allows you to execute third-party applications, or perform actions on certain events, even based on 3rd party webhooks. The entire system is meant for customization – the four different API use cases, the code execution, the Make.com apps, the Google Chrome extensions all support this goal.
But this is not the end of it! We understand that customer-facing interfaces make or break a business, no matter if it is an enterprise department or an LSP. So we created a customer/project management portal, but instead of selling it as-is, our approach is giving access to the source code. The portal itself was developed by senior developers with intense usage of Claude Code, and is fully built on the foundation of BeLazy’s project ingestion API. One of the design principles was that we wanted this portal to be easily customizable with the help of vibe coding and it is. As a result, customers can deploy several different portals for different uses within the organization, making every internal customer feel completely addressed.
Strategic control
When you buy technology from a 3rd party, of course it is hard to fully control it. However, the main reason for controlling is usually the need for customization, the need for extension, and the need for cost control, and here BeLazy checks all the boxes. And more importantly, BeLazy is a platform to exert strategic control over your other language technology. If you build your entire platform around a TMS, if the TMS changes the licensing, you are cornered – you can start from scratch. As Jim Compton put it, “the real risk, if you go the build-your-own route, is that you are anchoring your future to your imagination.” If you use BeLazy, you define and learn the use cases, the integration patterns, and if at some point later you want to move towards a TMS-oriented infrastructure, you do not have to change the logic – BeLazy already showed you how you need to work. One of the biggest values of BeLazy is that it is a repository of productized best practices. We spend around 40% of our development budget on experimentation. The solutions are proven with multiple customers, and they are extensible with new use cases. BeLazy’s architecture has reached its limits in certain aspects in the past, but now with seven years of experience in full automation, we do not hit such boundaries. Integration’s happy path is easy, until it becomes hard due to error handling, exception-handling, limitation handling of different systems. If you have not integrated at least 3-4 systems of the same kind, you are unlikely to know about all the roadblocks you will hit. As Laszlo Varga puts it:
“… complexity of these platforms do not just come from the number of features but the underlying architecture that applies across features and use cases. These often highly specific and algorithmic designs for localization have already been mapped out by the vendors over decades of working with enterprise localization teams, and the current best-of-breed language systems incorporate all that industry knowledge irreplaceable by AI-coding by engineers who have never worked on localization infrastructure before.”
Nimdzi
The buying reasons
Now that we looked at the reasons why companies build, and explained how these aspects are addressed by BeLazy, it is time to look at the reasons why companies buy, to see how we at BeLazy combine the best of both worlds.
Lower operational complexity
This is a very important one. BeLazy is a harmonization platform – which means it teaches you one integration logic and pushes that through the various systems. This may take a little time, but once you understand how metadata is the central organizational concept, and see how every configuration is based on metadata-driven rules and exceptions, and understand the bundling concept which is not available in such a clean way in any other tool, you will know how integration works. Even if you plan to build later, you can learn from BeLazy – we are generous with knowledge, and take pride in retaining customers because what we do adds value that they would otherwise take a long time to achieve.
Besides the metadata handling, the unified error handling, the use case based system categorization, BeLazy also offers expert-driven best practices. The project management Google Sheet can easily accommodate any type of content. The JSON format used for AI integration saves you up to 80% of the tokens as opposed to using XLIFF. We did not build these because they were absolutely necessary – we built them to optimize operations. These are things that everyone could develop, but team members with 10+ years of experience in solving such problems just think about more things naturally than somebody who faces the problem for the first time.
Access to advanced capabilities
Frankly, customizability and low operational capability is already an advanced capability… But if you look at instruction mapping, to build strings from incoming data for sharing with stakeholders, if you look at the email assistant, which automates email-based projects, if you look at the many fine-tuned connector capabilities, you’ll find that the system is built on experience, and that BeLazy engineers are not frightened by addressing technical complexity.
Faster deployment
Simple connections take a day or two to configure and test and refine. New connectors, depending on the technology we use, can take days or weeks, or in certain complicated situations, 2-3 months (if we are not allowed to use APIs, if there are 2-factor authentications to go around). Our experience is that very often the internal inertia is holding back the deployment more than the technical capabilities, but most organizations get there.
Vendor support / SLA
The way BeLazy works is that in the BeUnstoppable annual plan we include 20 so-called development credits. These are not about building new integrations, that’s a separate service if needed, but rather improving how a customer can work with existing capabilities. We understand that there are many reasons why the out-of-the-box solutions may not be enough for an organization, but at the same time customers also need to prioritize what is important, what they cannot change, and what they are just slow to improve. The development credits are prioritized and spent on a per-customer basis, enabling fully fine-tuned systems.
The standard SLA includes 99.5% availability of the platform, but in reality, it is way above 99.99%.
Predictable costs
BeLazy’s costing is based on the number of BMS (reporting) projects coming from the various content sources plus the availability of certain features, but customers can request unlimited TMS connections. For most organizations, costs are very predictable, with a from – to range.
The buying reasons
There’s a point in Nimdzi’s report that build-or-buy discussions usually skip over: whoever runs the transition, from scoping through sustained deployment, matters as much as whether you build or buy in the first place. Nimdzi puts it plainly:
“Enterprises, however, rarely have need (or budget) for a full-time solution architect with localization and content expertise, and no single expert has exhaustive knowledge and experience across all domains. The most strategic leverage in build decisions often comes from fractional, SA-led expert teams that provide high-value input without the overhead of fixed internal resources.”
Nimdzi
We’d go one step further, though. The solution architect role does not have to be an external one, and often it isn’t. It is an evolving role that today is a necessity, and a while ago it wasn’t – somebody in your organization is already filling it, most likely without the title. They’re the person who understands both the content and the systems well enough to be asked the hard questions, and who ends up making the calls nobody wrote a job description for. Finding that person, and giving them full explanations and the room to experiment, is one of the more overlooked keys to an organization’s success with technology.
This is also where we’d rather work alongside a solution architect or a consultant than replace one. They understand the customer’s working context in a way we never will, simply because of the time spent together – a third-party technology provider cannot substitute for that. What we can do is make their job faster: seven years of integrating the same handful of TMS-BMS-CMS combinations, across dozens of customers, means the metadata models, the bundling logic, the error handling, and the edge cases that only surface after the third or fourth integration of the same kind are already worked out. Whether the person planning your build-or-buy transition carries the SA title or just does the job, BeLazy is the platform that makes it faster, not the vendor they have to work around.
Re-creating what works is not innovation but opportunity cost.
When I read the article, I loved this quote. What are we NOT building because your best engineering talent is busy reinventing existing plumbing? When we started BeLazy, we decided to take over the burden of building a very solid plumbing. I am proud of what we built – customers often tell us not only about the stability of the system, but how well it handles the out-of-the-ordinary cases. This is what no organization can prepare for – if you knew what’s out-of-the-ordinary, you’d prepare for it. But this only surfaces later, like hidden cracks on the newly built wall. Nimdzi frames this exact moment well:
“The line between a successful proof-of-concept and a sustainable, enterprise-ready platform is often the difference between innovation and new, brittle technical debt.”
And this is where BeLazy is a solid foundation. Together with our total dedication to customers, any organization that is either integrating multiple systems or thinking about starting small and then expanding the scope of automation is better off with BeLazy. If there is a point-to-point integration, most brilliant engineers can come up with integrations that work, however, this takes them time. But when it comes to a unified framework, what we build is the result of seven years of full-time learning. That is invaluable.
Nimdzi runs exactly this kind of audit for its enterprise clients: weighing the real total cost of ownership against the promise of a build. We’d welcome that same scrutiny pointed at us. Numbers that can’t survive an independent audit aren’t numbers worth building a strategy on, ours included.
