What is the best tech stack for a translation or localization agency in 2027?

The two real stack architectures, compared head to head

Almost every localization agency ends up choosing between two coherent architectures, and the choice is not really about features — it is about where the linguistic asset lives and who controls the vendor relationship. Understanding the split matters more than comparing feature checklists, because switching architectures later means migrating translation memories, retraining project managers, and re-onboarding a freelance roster.

Architecture A — the owned-core stack. The agency licenses a production TMS (Phrase, Trados/RWS, or memoQ), stores translation memories and termbases on a server it controls, runs the business on a purpose-built BMS (Plunet, XTRF, Protemos, or LBS Suite), and sources linguists through its own vetted roster held in the BMS vendor portal. Machine translation is integrated into the TMS as a layer, not a separate tool. This is the classic language service provider (LSP) shape and the one that most mid-size and large agencies run. Its defining property: the translation memory is a company-owned asset that compounds, and the vendor relationships are direct.

Architecture B — the platform-native stack. The agency runs asset-light on a combined marketplace-plus-TMS platform — Smartcat is the clearest example — where sourcing, the CAT editor, the translation memory, and global contractor payments all live inside one vendor's system. Continuous-localization specialists build a variant of this on Lokalise, Crowdin, or Transifex wired directly into client Git repositories and design tools. Fixed software cost drops sharply, vendor administration mostly disappears, and a two-person shop can service a twenty-language launch. The trade: platform fees scale with revenue rather than headcount, the toolchain is someone else's roadmap, and the linguistic asset sits inside a system you rent.

The honest comparison on the dimensions that decide margin:

Translation memory leverage. Architecture A wins decisively at volume. When you own a consolidated server-side TM across every account, a large recurring client can hit 40-70% repetitions and high-fuzzy matches, and those words bill at a fraction of the new-word rate. Architecture B still gives you TM, but fragmentation risk is higher when work is spread across marketplace linguists and platform workspaces, and export rights matter enormously.

Speed to first invoice. Architecture B wins. A boutique can be quoting, producing, and paying linguists within a week on a platform-native stack. Standing up a TMS, importing legacy TMs, configuring a BMS, and onboarding a vendor roster in Architecture A is a genuine 60-90 day project.

Client mandates. Architecture A wins on enterprise deals. A meaningful share of enterprise and government buyers still specify Trados compatibility, on-premise or region-locked TM storage, and documented vendor NDAs. If your pipeline includes regulated industries, the owned-core stack is not optional.

Cost curve shape. Architecture A is mostly fixed — seats, BMS subscription, MT volume — so margin improves as revenue grows. Architecture B is mostly variable — platform fees and per-word marketplace margins — so it stays cheap when small and gets expensive at scale. The crossover for most agencies sits somewhere in the low seven figures of annual revenue.

The hybrid that most successful agencies actually run. In practice, the mature answer is not purely A or B. A mid-size agency runs an owned core (Phrase or Trados plus Plunet or XTRF) for its named accounts, and uses Smartcat or a marketplace for surge capacity, exotic language pairs, and one-off work where building a vetted roster is not worth the effort. Software-localization work runs on Lokalise or Crowdin because those tools connect to the client's repository, while document and marketing work stays in the document-centric TMS. Treat the two architectures as a spectrum you position on, not a religion.

How to decide between them

The decision is driven by four inputs in a fixed order: client mandates, volume and recurrence, language-pair breadth, and team size. Work them in that sequence, because an earlier input can override every later one.

Start with client mandates, because they are binary. If a significant client or your target segment specifies Trados compatibility, TM ownership clauses, ISO-aligned process documentation, or data residency requirements, Architecture A is decided for you. No amount of platform convenience overcomes a procurement requirement. Ask your top five accounts what their contracts actually say about translation memory ownership and tool compatibility before you shop for anything.

Then measure recurrence, not just volume. The economics of the owned core come from reuse, and reuse comes from repeat content — product documentation that gets revised, UI strings that get extended, marketing templates that get localized quarterly. An agency doing 500,000 words a year of one-off, never-repeating content gets far less TM leverage than one doing 200,000 words a year of versioned documentation. Pull last year's jobs and estimate what fraction of words came from clients who sent similar content more than twice. Above roughly 40%, the owned core pays for itself quickly.

Then look at language-pair breadth versus depth. An agency working eight core European pairs deeply can maintain a vetted roster and a well-curated termbase per client. An agency asked for forty pairs including low-resource languages cannot realistically vet and manage that many linguists directly — marketplace sourcing becomes the practical answer for the long tail even if the core stays owned.

Only then consider team size and budget. Below roughly ten people, the coordination overhead of a full BMS often exceeds its benefit, and Protemos or a platform-native approach is genuinely correct. Between roughly fifteen and forty people, the spreadsheet approach starts leaking margin and the BMS becomes urgent.

The tiebreaker nobody applies but should: who on your team will administer this. A BMS like Plunet is powerful and genuinely requires an owner — someone who maintains rate cards, workflow templates, and the vendor database. If no one on the team has the bandwidth to own it, buying it produces an expensive, half-configured system that people work around in spreadsheets anyway. Platform-native stacks demand far less administration, and that is a legitimate reason to choose one.

Concrete numbers behind each layer

Prices move, tiers get renamed, and enterprise deals are negotiated — so treat these as planning bands rather than quotes, and verify current pricing directly with each vendor before you budget.

TMS and CAT core. Phrase (the combined Memsource and Phrase TMS platform) typically runs in the range of roughly $27 to $80+ per user per month depending on tier, with enterprise agreements quoted above that band. Trados Studio from RWS is licensed per linguist in a roughly $300-$540 range for a professional license, plus GroupShare when you want server-side shared translation memory. memoQ licenses in a comparable band to Trados, with memoQ server or cloud priced separately. The practical planning rule: budget per production seat, not per employee — project managers and linguists need different license types, and freelancers often bring their own Trados or memoQ licenses.

Developer-facing TMS. Lokalise team plans commonly start somewhere around $120-$230 per month and scale with seats, languages, and key counts. Crowdin and Transifex occupy similar territory with different pricing axes — Crowdin tends to price on strings and projects, which matters if you have many small projects rather than a few large ones. Model your actual key or string count before comparing, because the same volume of work can price very differently across these three.

Enterprise TMS. Smartling, XTM Cloud, and Wordbee are enterprise-quoted, generally landing in the low five figures per year and up depending on volume, connectors, and managed services. At this tier the per-seat number stops driving the decision; connector breadth, workflow governance, and support SLAs do.

Machine translation. DeepL API and Pro plans start around $25 per month for small usage and scale into volume-based enterprise pricing. Google Cloud Translation and Microsoft Translator bill per character, which makes them predictable to model — take your annual word count, multiply by roughly five to six characters per word, and price against the published per-million-character rate. ModernMT prices adaptive MT that learns from your own translation memory, which is worth a premium only if you actually have rich, clean domain data to feed it. LLM-based post-editing prompted with your termbase and style guide is increasingly a fourth option; price it on tokens and pilot it on one language pair before committing.

Business management system. Plunet BusinessManager is enterprise-quoted and typically lands in the four-figure to low-five-figure annual range depending on user count and modules. XTRF sits in comparable territory, especially when bundled with XTM Cloud. Protemos is the affordable end — free at small scale, rising to a few hundred dollars a month — and it is genuinely sufficient for a boutique. LBS Suite is a European-favored alternative in the mid band.

Quality assurance. Xbench from ApSIC has a free legacy version and a low-cost subscription; Verifika is the modern alternative in a similar low band. This is the cheapest insurance in the entire stack — a subscription costs less than one re-delivery caused by a terminology or tag error.

Accounting and BI. QuickBooks Online runs roughly $30-$200 per month depending on tier; Xero roughly $15-$80. NetSuite is the multi-entity answer at meaningfully higher cost. Power BI at roughly $14 per user per month is the common BI default; Looker Studio is the free alternative if your data already sits in Google's stack.

Rolled up by agency size. A boutique of two to fifteen people typically lands around $300-$1,500 per month in total software: memoQ or Phrase seats, Protemos, DeepL Pro, Xbench, QuickBooks. A mid-size localization agency of forty to a hundred and fifty staff typically runs roughly $3,000-$15,000 per month: Phrase or Trados across the team, Plunet or XTRF, marketplace or vendor portals, MT at volume, Xbench, accounting, and Power BI. A large LSP at 250-plus staff runs $25,000 per month and up, adding enterprise TMS, custom or adaptive MT trained on owned data, a data warehouse, and dedicated integration engineering.

The ratio that matters more than any absolute number. Track total stack cost as a percentage of revenue. Healthy localization agencies generally keep production software well inside single-digit percentages of revenue. If your stack cost is climbing as a share of revenue while word volume grows, something is wrong — usually duplicated tools, unused seats, or MT being paid for twice because it is bought both standalone and inside the TMS.

Implementation details and sequencing

Sequencing matters because each layer depends on the one before it. Standing up a BMS before you have consolidated translation memories means you will configure workflows around a production reality that is about to change.

Days 0-30 — stand up the production core and rescue the translation memories. Choose the TMS and configure it, but spend most of this month on TM archaeology. Find every translation memory the agency has ever created: in old Trados packages, in project folders on shared drives, in departed project managers' accounts, and — the painful one — on freelance linguists' laptops. Consolidate them into a server-side store the agency owns. Clean as you go: deduplicate segments, strip TMs that were built from unreviewed machine output, and tag by client and domain so you can segment access later. Establish the termbase in the same pass, starting with your three highest-volume clients. Set up connectors for the top client content systems — CMS, repository, or file store — and migrate active projects last, once the core is stable.

Days 30-60 — integrate machine translation and deploy the business system. Wire the MT engine inside the TMS so translation memory matches and termbase entries feed the engine and the linguist post-edits in the same editor. This is the step agencies most often get wrong, and getting it right is what converts MT from a cost into leverage. Define your MTPE workflow explicitly: which content types are eligible, what the quality bar is, what the per-word rate is for light versus full post-editing, and how linguists log effort. Then deploy the BMS and connect it: word counts and match categories must flow from the TMS into quoting and invoicing automatically. Link accounting last.

Days 60-90 — onboard vendors and instrument the numbers. Load the linguist roster into the vendor portal or marketplace with rate cards by language pair and service type, specializations, availability, signed NDAs, and a quality-scoring field. Formalize purchase-order issuance and payment timing — freelancers leave agencies over slow payment more than over rates. Then stand up reporting: TM reuse rate by client, MTPE leverage, margin per language pair, vendor quality trend, and on-time delivery. If you cannot see margin per language pair by day 90, the implementation is not finished.

The integration that is genuinely non-negotiable: TMS to BMS. Word counts, match categories, and language pairs have to flow from the production core into quoting and invoicing without human retyping. Break that wire and per-word billing becomes manual arithmetic across dozens of concurrent jobs, quotes drift from what was actually produced, and margin tracking degrades into guesswork. Verify this integration works on real project data during evaluation, not from a demo.

The four failure modes to design against. First, fragmenting or losing translation memories — the fix is a single server-side, agency-owned TM that every project writes back to. Second, bolting MT on as a disconnected browser step, which throws away TM leverage, termbase enforcement, and the audit trail. Third, running the business on spreadsheets past a handful of concurrent projects, where word-count and rate errors quietly erode margin. Fourth, treating the freelance pool as an unmanaged contact list, with no rate cards, no quality scores, and no availability data, which makes matching the right linguist to the right job slow and unreliable.

Change management is the hidden cost. Linguists have strong tool preferences and real productivity differences between editors. Migrating a roster from memoQ to Phrase costs real throughput for weeks. Pilot with a small group, keep the old tool available for in-flight work, and budget for the dip rather than pretending it will not happen.

Related questions

Should a small agency skip the BMS entirely at first?

Yes, up to a point. Below roughly ten people and a handful of concurrent projects, Protemos or even disciplined spreadsheets work. The signal to buy is when quoting errors, missed purchase orders, or unbilled work start appearing — usually somewhere between fifteen and forty staff.

Does machine translation reduce what an agency can charge?

It shifts the mix rather than simply cutting revenue. MTPE bills at lower per-word rates but processes far more words per day, and it wins volume that would otherwise go elsewhere. Agencies that integrate MT well grow total revenue; those that ignore it lose price-sensitive work outright.

Who should own the translation memory, the agency or the client?

Contracts increasingly assign TM ownership to the client, with the agency holding it under license. Negotiate explicitly rather than leaving it ambiguous, keep client TMs segregated, and make sure your tooling can export cleanly in TMX so an ownership change never becomes a technical crisis.

Do we need a separate tool for software string localization?

If software strings are a meaningful share of your work, yes. Lokalise, Crowdin, and Transifex connect to repositories and design tools in ways document-centric systems do not. Run them alongside your main TMS rather than trying to force one tool to do both jobs well.

How many language pairs justify a vendor marketplace?

There is no hard threshold, but once you are regularly asked for pairs outside your vetted roster — particularly low-resource languages — marketplace sourcing beats trying to recruit and qualify linguists you will use twice a year. Keep the core pairs on your own roster.

FAQ

Do we really need a business management system, or can the TMS handle everything?

Past boutique size, you need both. The TMS handles production — CAT editing, translation memory, machine translation, quality assurance. The BMS handles quoting, vendor purchase orders, invoicing, and margin reporting across many concurrent jobs. Plunet, XTRF, and Protemos exist because per-word, per-language billing and freelance vendor management overwhelm a production tool. Smartcat is the notable exception, blending both for marketplace-model agencies.

Phrase, Trados, or memoQ — which should we actually pick?

Choose Phrase for cloud-native collaboration and broad connector coverage, Trados when enterprise clients mandate it or you need its established ecosystem, and memoQ when linguist editor experience and quality workflows are your differentiator. All three are credible production cores. The real differentiator is your client base and whether your team works cloud-first or desktop-first.

How important is translation memory ownership in practice?

It is the most consequential asset decision in the stack. Translation memories are reusable linguistic data that compound across projects and directly lower cost per word. Store them server-side under clear ownership terms, never solely on a vendor platform you cannot export from or on a freelancer's machine. Confirm TMX export works before you sign anything.

Can we run a serious localization agency entirely on a marketplace platform?

Yes, and some do successfully — asset-light agencies combine marketplace sourcing, TMS, and global contractor payments in one platform, layering machine translation or LLM post-editing on top. The trade-offs are platform fees that scale with revenue, less control over the toolchain, and difficulty satisfying enterprise clients who mandate specific tools or data residency.

What is the fastest way to lose margin with the right tools installed?

Fragmented translation memories and disconnected machine translation. If TMs live in project folders rather than a shared server-side store, reuse collapses and every project pays full new-word cost. If linguists paste content into a browser MT tool and paste results back, you lose termbase enforcement, match leverage, and any audit trail. Both are configuration failures, not licensing failures.

How long does a full stack implementation realistically take?

Roughly ninety days for a mid-size agency that commits a named owner to the project, with translation memory consolidation consuming most of the first month and often running longer than planned. Boutiques standing up a lean core can be productive in two to three weeks. The variable that decides the timeline is almost always TM archaeology, not software configuration.

Sources

• https://phrase.com/pricing/
• https://www.rws.com/localization/products/trados/
• https://www.memoq.com/
• https://www.plunet.com/en/
• https://xtrf.eu/
• https://www.deepl.com/pro-api
• https://cloud.google.com/translate/pricing
• https://www.smartcat.com/
• https://lokalise.com/pricing
• https://www.gala-global.org/

Related on PULSE

• [What is the recommended AI Translation API sales and operations tech stack in 2027?](/knowledge/tk0269)
• [The Recruiting and Staffing Agency Tech Stack in 2027](/knowledge/tk0509)
• [The Agency Operations Stack: Project, Time, and Client Billing in 2027](/knowledge/tk0508)
• [The Insurance Agency Tech Stack: Quoting, Policy, and Claims in 2027](/knowledge/tk0502)
• [What is the complete software stack for a software development agency in 2027?](/knowledge/tk336)
• [What is the complete software stack for a staffing agency in 2027?](/knowledge/tk0331)