The line item that started the fight was a single number in a slide deck: $340,000. That was the first-year quote to build Freya's company a custom machine-translation engine, trained on eleven years of accumulated translation memory across forty-one language pairs, promised to lift quality "beyond what any off-the-shelf model can do." Freya ran localization for a firm that shipped industrial-automation software and its safety documentation into those forty-one markets, and the vendor pitching the build was good, genuinely good, with a deck full of graphs curving up and to the right. Across the table sat her VP of engineering, who wanted the custom engine because custom sounded like control, and her CFO, who wanted the cheapest general engine because a subscription is easier to cancel than a capital project. Freya wanted neither reflex. She wanted the answer, and she knew the answer was not a slogan. It was a calculation with data volume on one axis, consequence on another, and a maintenance bill that nobody in the room had put on a slide. This lesson is that calculation, built slowly, because the difference between a localization operation that spends $340,000 wisely and one that spends it on a machine it cannot feed is the difference between a strategist and someone who bought the deck.

The Three Paths, Defined Before You Argue Them

Every localization-AI engine decision collapses, underneath the vendor language, into three paths, and the first discipline is to name them precisely so the argument in the room is about the right thing. Start with the vocabulary, because half of every bad build-versus-buy decision is made by people using the same words to mean different machines.

Machine translation (MT) is any system that turns source-language text into target-language text with no human writing the words. Neural machine translation (NMT) is the dedicated-model form: an engine trained specifically to translate, which is what most computer-assisted-translation (CAT) tools and translation-management systems (TMS) have run for years. A large language model (LLM) is a general-purpose text predictor that translates as a side effect of its broad fluency, which makes it more fluent, more steerable by instruction, and more confidently wrong than a classic NMT engine. When this lesson says "engine," it means whichever of these produces your first-pass output.

Now the three paths. Buy means licensing a general, hosted engine as it comes: a commercial NMT service or an LLM behind a translation prompt, used out of the box, priced per character or per token or per seat, with the vendor owning the model and its upkeep. You configure it, you do not change its weights. Tune means taking a base engine and adapting it toward your content. Here two distinct techniques hide under one word, and conflating them is the most common technical error a strategist makes, so pull them apart now.

Fine-Tuning, Adaptation, and Grounding Are Not the Same Lever

Fine-tuning is retraining a base model's actual weights on a corpus of your paired source-and-target segments, so the model's internal parameters shift toward your domain's style, terminology tendencies, and phrasing. It changes the engine itself, and it is a training job with a training cost, a training dataset, and a training-data-quality problem. Adaptation is the broader family that includes fine-tuning but also lighter-weight methods that steer a model without a full retrain: parameter-efficient tuning that adjusts a small fraction of weights, or provider "custom model" and "adaptive MT" features that learn incrementally from your corrections. The shared idea is that the model's behavior is bent toward you and the change persists inside the model.

Set both against a third lever that is not tuning at all, though vendors love to blur the line. Grounding is supplying your linguistic assets to a general engine at the moment of translation, without changing the model's weights: feeding the approved termbase (the controlled glossary of mandated terms) as a constraint, retrieving matching segments from your translation memory (TM) to show the engine how you rendered similar content before, and injecting the relevant style-guide rules into the prompt. The engine stays generic; you change what it sees, not what it is. Retrieval-augmented generation, where the pipeline fetches your own segments and terms and hands them to the model as context, is the industrial form of grounding.

Fine-tuning changes the engine. Grounding changes what the engine sees. Most operations that think they need to build or fine-tune actually need to ground a bought engine properly first, because grounding is faster, cheaper, and reversible, and it fixes the exact failures they blame on the base model.

The third path is build. A custom engine means training a translation model substantially from your own data, or training a domain-specialized model from a base architecture, so the engine is materially yours: your data shaped it, you host or own it, and its maintenance is your responsibility rather than a vendor's. In practice, in 2026, very few localization operations build a from-scratch engine, because a general foundation model plus adaptation plus grounding reaches most of the quality a bespoke build once promised at a fraction of the cost and risk. But "build" remains the correct label for the heaviest end of the spectrum, the $340,000 line item, and a strategist has to be able to say when it is genuinely warranted and, far more often, when it is a capital trap dressed as control.

What You Are Actually Buying, and What You Inherit

The three paths are not three prices. They are three bundles of cost, control, data burden, maintenance, and risk, and the trap is that vendors quote you the price and stay silent on the other four. Walk each bundle deliberately, because the strategist's job is to see the whole bundle before the room votes on the one number in it.

The Buy Bundle: Cheap to Start, Generic by Nature

When you buy a general engine you buy speed of adoption and you inherit generality. The cost is operating expense, predictable and cancellable, with no training data required from you and no model maintenance on your books, because the vendor retrains and improves the model on their schedule. That last clause is the double edge: the vendor improving the model on their schedule means the engine gets better for free, and it also means the engine changes under you without warning, which matters enormously for a regulated operation that validated a specific behavior. What you do not get is any inherent knowledge of your terminology, your house style, or your domain's idioms beyond what the base model absorbed from the open web. The bought engine will render your approved device term with whatever common synonym it finds most probable, because it has never seen your termbase, and it will do so fluently, which is precisely the dangerous kind of wrong.

The crucial, underappreciated fact about the buy path is that most of its perceived weaknesses are fixable without leaving it. A bought engine that drifts off your terminology, ignores your style, and does not know your product names is not a reason to fine-tune or build; it is a reason to ground the bought engine on your termbase, TM, and style guide, which lifts adherence dramatically at a fraction of the cost and none of the maintenance of tuning. A great many operations skip this step, conclude the general engine "is not good enough for our domain," and leap to a six-figure build to solve a problem a well-supplied glossary and a retrieval layer would have solved for a rounding error. Rule out grounding as the fix before you spend anything on changing the model.

The Tune Bundle: You Now Own a Dataset Problem

When you tune, whether by fine-tuning weights or by an adaptive-MT feature, you buy domain fit and you inherit a data problem and a maintenance problem, in that order of surprise. The moment you commit to tuning, your bottleneck stops being the model and becomes your data: fine-tuning learns whatever your training corpus teaches it, which means it learns your errors, your inconsistencies, your abandoned old terminology, and your one linguist's idiosyncratic phrasing just as faithfully as it learns your good work. Garbage in, fluent garbage out, at scale, baked into the weights where it is far harder to see and undo than a single bad segment in a file. This is the hidden cost that sinks most tuning projects: the belief that you have "eleven years of translation memory" as an asset, when what you actually have is eleven years of unaudited, un-deduplicated, term-drifted, mixed-quality segments that will teach the model as much bad behavior as good unless someone cleans them first, and cleaning them is real, expensive, skilled human work.

Then comes the second inheritance, the one nobody demos: drift and retraining. A tuned model is a snapshot of your content and your terminology at the moment you trained it. Your terminology evolves, your product line changes, a regulated term gets redefined, your house style shifts, and the tuned model does not know, because it froze when training stopped. Over months, the gap between what the model learned and what your current standard requires widens: this is drift, and the only cure is retraining, which means assembling a fresh clean corpus and running the training job again, on a cadence, forever. Tuning is not a purchase; it is a subscription to a maintenance obligation you now own, and the annual retraining cost, the data-preparation labor, and the re-validation of the retrained model belong on the slide next to the training quote. They almost never are.

The training bill is the cheapest part of tuning. The expensive parts are cleaning the data before you train and retraining forever after you do. An operation that cannot fund the data prep and the retraining cadence cannot afford to tune, no matter how attractive the one-time training quote looks.

The Build Bundle: Maximum Control, Maximum Obligation

When you build a custom engine you buy the deepest possible fit and control, and you inherit everything: the largest data requirement (you need enough clean, in-domain paired data to shape a model, which is far more than tuning needs and far more than most operations possess), the highest maintenance burden (hosting, monitoring, retraining, and the specialized machine-learning talent to run it), and a concentration risk where your operation now depends on a machine that only you maintain. The control is real. So is the obligation, and the obligation compounds. A bought engine's improvements arrive for free; a built engine improves only when you fund the improvement. A bought engine's security and uptime are the vendor's problem; a built engine's are yours. The build path is the correct choice in a narrow set of circumstances, and the strategist's value is knowing exactly how narrow that set is, because the gravitational pull in most rooms, driven by the word "control," is toward building far more often than the economics justify.

When Fine-Tuning Genuinely Pays Off, and When a Glossary Suffices

Here is the question the whole lesson turns on, the one Freya had to answer before she could answer anything else: does this operation actually need to change the model, or does it need to change what the model sees? Because tuning and building are model changes, and they carry the data, drift, and maintenance bundles above, while grounding is a see-change, and it carries almost none of them. The strategist's default posture, the one that is right more often than any other, is: ground first, tune only when grounding provably falls short, build almost never.

What Grounding Fixes, Which Is Most of It

Grounding a bought engine on your termbase, TM, and style guide fixes the failures operations most often blame on the base model. Terminology drift, the engine preferring a common synonym over your mandated term, is fixed by supplying the termbase as a constraint, which lifts terminology-adherence rates from mediocre to near-perfect on the terms you supply. Inconsistency with past renderings is fixed by retrieving matching TM segments and showing them to the engine. House-style violations are fixed by injecting the style rules. Do-not-translate product names holding, formality register, preferred phrasings: these are grounding problems, and grounding solves them without a training job, without a data-cleaning project, without a retraining cadence, and reversibly, because tomorrow you can change the termbase or the retrieval set and the engine's behavior changes immediately with no retrain. When someone says "the engine does not know our domain," the first question is always: have we actually fed it our domain, or are we asking a generic model to guess at assets we never supplied?

What Fine-Tuning Adds That Grounding Cannot

Grounding has limits, and understanding them is how you know when tuning is genuinely earned rather than merely wanted. Grounding steers the model at inference with the context you supply, but it cannot teach the model a pervasive stylistic register that lives in thousands of small choices no glossary can enumerate, and it cannot fix a base model that is systematically weak on a low-resource language pair or a specialized domain where the general training data was thin. Fine-tuning genuinely pays off when three conditions hold at once. First, the gap between the grounded bought engine and your requirement is real, measured, and consistent, not a vibe: you have scored a grounded general engine on a representative test set and it still falls short in a specific, repeatable way. Second, the shortfall is the kind fine-tuning addresses, a pervasive domain style or a systematically weak language pair, rather than terminology or consistency, which grounding already handles. Third, you possess a large, clean, in-domain corpus, or can afford to build one, and you can fund the retraining cadence that keeps the tuned model from drifting. When all three hold, tuning earns its bundle. When any one fails, tuning is a project that will underdeliver against a well-grounded bought engine while costing far more, and the most common failure is the third: the corpus exists but is dirty, and nobody has budgeted the cleaning.

Fine-tuning pays off only when a grounded general engine has been measured and still falls short in a pervasive, style-or-language-pair way that grounding cannot reach, and you own a clean corpus and can fund perpetual retraining. If the shortfall is terminology or consistency, ground it; if the corpus is dirty and unfunded, do not tune.

The Cost Comparison That Anchors the Decision

Put rough shapes on the three paths so the decision has scale, remembering these are shapes to reason with, not quotes to trust. Buying and grounding a general engine is operating expense: a per-usage engine fee plus a modest, one-time engineering effort to build the retrieval and glossary-injection layer, then low ongoing cost, and the improvements arrive for free as the vendor retrains. Fine-tuning adds to that a data-preparation project (often the single largest line, because cleaning years of mixed-quality TM is skilled human labor), a training cost per run, and a retraining cadence that repeats that cost on a schedule, plus the validation of each retrained model before it goes live. Building a custom engine adds, on top of everything tuning requires, a far larger data requirement, model-hosting infrastructure, and specialized machine-learning staff whose salaries dwarf the training bill, which is why a $340,000 first-year quote is never a $340,000 total: it is a $340,000 down payment on a recurring obligation. The economics almost always favor grounding a bought engine, because it captures most of the achievable quality at the smallest and most reversible cost, and the burden of proof sits on anyone arguing to leave it.

The Hidden Costs Nobody Puts on the Slide

The reason build-versus-buy-versus-tune decisions go wrong is not that people are foolish about the visible number. It is that the visible number is the small one, and the large costs are structural, delayed, and easy to leave off a deck. Name them explicitly, because a strategist's contribution in the room is making the invisible costs visible before the vote.

Data Preparation: The First and Largest Hidden Cost

Every model change, tune or build, runs on your data, and your data is not ready. The comforting phrase "we have years of translation memory" hides the reality that a TM accumulated over years is a geological record of every terminology change, every quality standard you have ever held, every linguist's idiosyncrasies, and every propagated error nobody caught. Train on it raw and the model learns the sediment: the abandoned term you replaced three years ago, the two different translations of one concept from two different eras, the segment where a post-editor left a Critical error that then leveraged into forty files. Preparing that data, deduplicating, aligning, auditing terminology, removing confidential and personally identifying content per your data rules, filtering low-quality segments, is a real project with real skilled labor, and it is frequently larger than the training cost it precedes. Operations that skip it do not save the money; they spend it later, in the form of a tuned model that ships the errors it learned, plus the cost of discovering why. The data-preparation line is the one most often missing from the build deck, and its absence is the single best tell that the deck is a pitch and not a plan.

Drift and Retraining: The Recurring Hidden Cost

A tuned or built model is correct on the day it trains and slowly wrong every day after, because the world it learned keeps moving and the model does not. Terminology gets redefined, products launch and retire, style evolves, a regulator changes a required rendering, and the model, frozen at training time, keeps producing the old behavior with full confidence. This is drift, and there is no fix but retraining, which means the data-preparation project and the training run and the re-validation, again, on a cadence, for as long as you run the model. The recurring cost is not a footnote; over a multi-year horizon the sum of retraining cycles can exceed the original build. A bought general engine has no drift problem of this kind, because the vendor absorbs retraining and the engine tracks the frontier for free, which is a genuine and usually undercounted advantage of the buy path. When you compare a one-time build quote against a subscription, you are comparing a recurring cost you own against a recurring cost the vendor owns, and the honest comparison is total cost of ownership over years, not year one against year one.

The Changing Engine, Which Cuts Both Ways

The vendor improving a bought engine on their schedule is a benefit for most content and a specific hazard for regulated content, and a strategist must hold both truths. For high-volume, lower-liability material, the engine silently getting better is pure upside. For content where you validated a specific behavior to satisfy an auditor, a medical instruction, a legal clause, the engine changing under you without notice means your validation may no longer hold, and you may not know until an evaluation catches it. This is a real argument for the control a tuned or self-hosted model provides, because a model you own does not change unless you change it, and for regulated tiers that stability can be worth its maintenance cost. It is one of the few arguments for tuning or building that survives scrutiny, and it is an argument about control and validation stability, not about raw quality, which is why it applies to the regulated slice of your content and rarely to the bulk.

A Worked Decision, Start to Recommendation

Return to Freya and the $340,000 slide, and watch the framework produce an answer that survives the room. Her operation ships industrial-automation software and its safety documentation into forty-one language pairs. The content splits into three tiers she already classifies at intake: safety-critical documentation and regulated compliance content (highest consequence, where a flipped instruction or dropped negation is a life-safety and liability failure), the product UI and help content (medium consequence), and marketing, release notes, and internal knowledge-base content (high volume, low consequence). The build vendor's pitch was one engine, custom-trained on her eleven years of TM, for all of it. Freya refused to evaluate that as a yes-or-no. She evaluated it tier by tier, path by path, cost bundle by cost bundle.

The Diagnosis: What Was Actually Failing

First she asked the question the whole framework rests on: what specifically is the current bought engine failing at, and is it a see-problem or a model-problem? She ran the failing content through her general engine both ungrounded and grounded on her termbase and TM, and scored both against a representative test set using her MQM error typology under ISO 5060 (Multidimensional Quality Metrics, the analytic error framework, scored under the 2024 international standard for evaluating translation output). The result reframed everything. Ungrounded, the general engine drifted off her mandated automation terminology constantly, roughly four in five approved terms rendered as common synonyms, exactly the failure the build vendor had used to justify the custom engine. Grounded on the termbase, adherence leapt to the high nineties, and most of the "the engine does not know our domain" complaint evaporated. The problem the vendor proposed to solve with a $340,000 build was, for the majority of her content, a grounding problem she solved in an afternoon of pipeline work. That single finding killed the all-content build.

The Routing: Different Paths for Different Tiers

With grounding ruling out the build for the bulk, she routed each tier to its honest path. For marketing, release notes, and knowledge-base content, the high-volume low-consequence tier, she chose buy plus ground: the general engine, supplied with the termbase and TM at inference, post-edited lightly, capturing the vendor's free improvements and carrying zero model-maintenance burden. Building or tuning here would have spent capital to marginally improve content whose consequence did not justify it. For the product UI and help content, medium tier, she chose buy plus ground as well, with fuller post-editing and terminology enforcement, but she flagged one candidate for future tuning: a persistent, measured stylistic register the UI content required that grounding only partly delivered, to be revisited only if a clean UI-specific corpus could be assembled and the gap stayed real on re-test. A hypothesis to test, not a project to fund yet.

For the safety-critical and regulated tier, the framework produced its most interesting answer, and it was not "build." Grounding lifted quality here too, but the tier's governing metric was not average quality; it was the critical-error rate, the frequency of the ship-blocking errors that fail a file, and on that metric the grounded general engine, while good, still produced the occasional dropped negation in a safety instruction, and one Critical is one too many for content that can injure. The build vendor's promise of a custom engine did not credibly solve this either, because a custom engine trained on her imperfect TM would learn her data's own occasional errors and would still require full human verification on life-safety content regardless of how it was trained. So the regulated tier routed to full human translation or full post-editing with a one-Critical-fails gate, with a grounded engine allowed only as a first-pass draft that a fully competent human owns and verifies, never as an autonomous producer. The most valuable output of the analysis was the recognition that no amount of building or tuning removes the human from the life-safety tier, which meant the $340,000 engine would not even earn its keep where the stakes were highest.

The strategist's answer to build-versus-buy-versus-tune is almost never one path for the whole operation. It is a routing: ground a bought engine for the bulk, hold a tuning hypothesis to test where a measured style gap persists, and keep humans on the life-safety tier where no model change removes the accountability.

The Recommendation, and Why It Survived the Room

Freya walked back in not with a reflex but with a routing and a total-cost comparison. Her recommendation: buy and ground the general engine for the two lower tiers, capturing most of the achievable quality at operating-expense cost with no maintenance burden and free vendor improvements; keep the regulated tier on human-owned workflows behind a one-Critical-fails gate, where no engine investment changes the accountability; hold the single UI-style tuning candidate as a hypothesis, to be funded only if a clean corpus is assembled and the gap survives re-test; and decline the $340,000 build outright, because it solved a grounding problem with capital, ignored the data-preparation and retraining costs entirely, and would still leave the life-safety tier requiring full human verification.

When the VP of engineering pressed on control, Freya did not dismiss it: she agreed control matters, and named the one place it earned its cost, the regulated tier's need for a model that does not change under an auditor, then showed that even there the answer was human ownership, not a custom engine, because the custom engine would have learned her TM's own errors and still needed the human gate. When the CFO reached for the cheapest ungrounded general engine, Freya showed the ungrounded critical-error and terminology numbers and demonstrated that grounding, not a cheaper contract, was the cost-effective quality lever. The $340,000 slide did not survive contact with a tier-by-tier cost bundle and a grounded-versus-ungrounded score. The routing survived, because every path in it was justified by a measured gap, a named cost bundle, and a consequence tier an auditor could re-derive. That is the difference between buying a deck and making a decision, and it is the entire reason the strategist, not the vendor, chooses the engine strategy.

Key Takeaways

• The three paths are buy (license a general engine as-is, operating expense, no data or maintenance burden, but generic and changing under you), tune (adapt or fine-tune a base model toward your data, buying domain fit while inheriting a data-cleaning problem and a perpetual retraining obligation), and build (train a substantially custom engine, buying maximum control and inheriting the largest data, hosting, staffing, and maintenance burden of all).
• Fine-tuning changes the engine's weights; grounding changes only what a bought engine sees at translation time by supplying the termbase, TM, and style guide. Most operations that believe they need to tune or build actually need to ground a bought engine first, because grounding is cheaper, faster, and reversible, and it fixes the terminology-drift and consistency failures they blame on the base model.
• The default strategist posture is ground first, tune only when grounding provably falls short, build almost never. Grounding fixes terminology, consistency, do-not-translate, register, and style-guide adherence without a training job or a retraining cadence.
• Fine-tuning genuinely pays off only when three conditions hold together: a grounded general engine has been measured on a representative test set and still falls short in a pervasive style or systematically weak language-pair way that grounding cannot reach; you own or can build a large, clean, in-domain corpus; and you can fund the perpetual retraining that keeps the tuned model from drifting. If the shortfall is terminology or consistency, ground it instead.
• The hidden costs sink tuning and build projects: data preparation (cleaning years of term-drifted, mixed-quality, error-carrying TM is skilled labor, often the single largest line and the one most missing from the pitch), drift and retraining (a tuned model is correct only on training day and needs perpetual retraining as terminology and style evolve), and the maintenance and staffing a self-owned engine demands forever.
• A one-time build quote is never the total cost. It is a down payment on a recurring obligation you now own, and the only honest comparison against a bought subscription is total cost of ownership over years, where a bought engine's free vendor improvements and absorbed retraining are a genuine, usually undercounted advantage.
• The vendor improving a bought engine on their schedule cuts both ways: pure upside for high-volume low-liability content, but a specific hazard for regulated content whose validated behavior can change under you without notice. That validation-stability argument is one of the few real cases for the control a tuned or self-hosted model gives, and it applies to the regulated slice, not the bulk.
• The right answer is almost never one path for the whole operation but a tier-by-tier routing: buy and ground for the high-volume tiers, hold a tuning hypothesis to test where a measured style gap persists, and keep humans on the life-safety tier behind a one-Critical-fails gate, because no model change (bought, tuned, or built) removes the human accountability from content that can injure or sue.