CTO's buyer framework: evaluating localization vendors on architecture, not feature lists

Every localization RFP response now includes an "AI-powered" slide, an "AI Hub" logo wall, and a glossary/TM/connector matrix that looks identical across five vendors. If you're the CTO signing off on this purchase, that matrix tells you almost nothing about whether the system will hold up once your product teams, support org, and AI agents all need to call it programmatically at once.

The feature checklist answers "what can this tool do inside its UI." It does not answer the question that actually determines whether localization becomes infrastructure or stays a bottleneck: can this system be invoked as a service, or does every workflow eventually route back through a human clicking buttons in someone else's application. That is an architecture question, and it needs an architecture rubric, not a feature comparison.

The argument: score the system, not the screen

Most vendor comparisons rank platforms by counting capabilities, glossary management, translation memory, CMS connectors, reviewer assignment. These are table stakes; nearly every vendor in the category has some version of each. What separates a platform you can build production pipelines on from one that will require a services team forever comes down to five architectural properties: whether the API surface is complete enough to run a workflow end-to-end without the UI, whether you're locked into one model provider, whether the system pushes state to you or makes you poll for it, how authentication is modeled for both humans and machines, and whether the underlying data structure maps to how your engineering org actually organizes work. Score vendors on these five, and the checklist differences mostly stop mattering.

Criterion 1: API completeness

The test isn't "does it have an API." Nearly everyone does. The test is whether the API covers the full lifecycle, including upload, order creation, status polling, QC, revision, and human-review escalation, or whether it's a thin ingestion endpoint that dumps you back into a web dashboard for anything beyond submitting a file.

Ollang's documentation describes programmatic uploads, orders, projects, revisions, QC, human review, and webhooks as first-class API operations, not a subset. That matters operationally. An engineering team can create an order, check its status, request a QC evaluation, escalate to human review, and open a revision, all without a human opening a dashboard. Ollang's API documentation documents each of these as discrete, callable operations, for example creating orders and retrieving them by filter and requesting human review programmatically on an existing order.

Score it: Can you complete an entire order lifecycle, create, monitor, QC, escalate, revise, using only the API? If any step requires the UI, mark it incomplete.

Criterion 2: Model neutrality and BYOK

This is the criterion most RFPs skip entirely, and it's the one with the largest long-term cost. A platform that hard-codes you to one model provider inherits that provider's pricing changes, rate limits, deprecations, and data-handling terms. A platform that lets you bring your own provider key gives you direct control over which model runs your translation traffic, and lets your security team negotiate data terms directly with the model vendor instead of through an intermediary.

BYOK appears as a named, documented concept in Ollang's platform reference, alongside the other primitives that make up the operational model. Folders, Projects, Orders, Levels, Workflows, Review Gates, LSPs, QC, BYOK, and more are treated as concepts a technical integrator needs to understand before building against the API, not as marketing bullet points buried in a features page.

Score it: Ask the vendor directly, can we supply our own model provider key, and does that choice apply to programmatic calls, or only to a UI toggle? If it's UI-only, it's not an architectural property; it's a preference setting.

Criterion 3: Webhook and callback support

Polling doesn't scale. If your pipeline has to repeatedly ask "is it done yet," you're building brittle cron jobs instead of an event-driven system. The alternative is a callback model: you submit a job, the system does the work, and it tells you when it's finished by hitting a URL you control.

Ollang's QC evaluation endpoint accepts a callback URL directly in the request payload. Accuracy, fluency, tone, culturalFit, customPrompt, and callbackUrl are all parameters on the same call, and the evaluation runs asynchronously and you will be notified when it's completed. Specifically, when a callbackUrl is provided, Ollang sends a POST request to the URL once the QC evaluation completes. That is the difference between infrastructure you can wire into a CI/CD-style pipeline and a tool you have to babysit.

Score it: Does the vendor support callbacks on long-running jobs (dubbing, large document sets, QC evaluations), or is polling the only option? Ask specifically about retry behavior on failed callback deliveries, Ollang's documentation treats retries as part of the production-readiness guidance alongside pagination and error handling, which is the level of specificity you should expect from any vendor claiming to be call-ready.

Criterion 4: Auth model for machines, not just people

Human-facing SSO is a solved problem across the category. The question that matters for infrastructure evaluation is whether the system has a distinct, stable authentication path for machine callers, API keys, service accounts, or scoped tokens, that doesn't depend on a logged-in browser session.

Ollang's REST API is API-key authenticated, with the key passed as a request header on every call, as shown consistently across the reference documentation for file upload, order retrieval, and project listing endpoints. Separately, for agentic access, Ollang exposes a hosted Model Context Protocol server using OAuth 2.0 with PKCE that drops into Claude, Cursor, Claude Code, Devin, Replit, Windsurf, and more. That is an architectural distinction: a static API key model for service-to-service integration, and a separate OAuth-based flow for autonomous agents that need scoped, revocable access rather than a long-lived static secret.

Score it: Does the vendor separate "human logs into dashboard" auth from "machine calls API" auth? If AI agents are meant to call the vendor directly, does the vendor have a real MCP or equivalent agent-access story, or is "AI-agent-ready" just a slide with no protocol behind it?

Criterion 5: Data structure, folders, projects, orders

This one gets skipped because it feels like a UI concern, but it's actually a systems-design question. If a platform's underlying data model doesn't map cleanly to how your organization structures work, for example by product line, market, or content type, every integration becomes a mapping exercise your engineers redo for every new use case.

Ollang documents this explicitly as a concept integrators need before writing code: the Folder → Project → Order hierarchy and why it matters is called out as required reading in the conceptual documentation, separate from the API reference itself. That is a signal the vendor thinks about the data model as a stable contract, not an implementation detail that changes with every UI redesign.

Score it: Ask for the entity-relationship model in writing, independent of screenshots. If the vendor can't describe it without opening the dashboard, the hierarchy probably isn't stable enough to build against.

Why "AI Hub" routing is a feature, not an architecture

Several incumbent TMS vendors now market a "multi-model AI Hub," a screen where a project manager picks which LLM handles a given job. It is a useful feature for a human operator. It is not architecture, and conflating the two is where a lot of RFPs go wrong.

The test is simple: can an external system, your pipeline, your agent, a script running in CI, select and swap the model programmatically, or does model selection only exist as a dropdown inside a web session? If the routing logic lives entirely behind a UI click, then from an integration standpoint you still have a single fixed backend, whatever the human happened to select last. Model neutrality that isn't callable is a merchandising decision, not an infrastructure guarantee. It does not reduce vendor lock-in, and it does not give your security team the direct provider relationship a real BYOK implementation provides.

The scorecard

Use this during RFP evaluation. Score each vendor 0-2 per row (0 = not present, 1 = present but UI-only, 2 = present and fully programmatic).

A vendor scoring 8-10 is infrastructure you can build on. A vendor scoring 3-5 is a tool with an API bolted on. Anything below that is a UI with a marketing deck calling it "AI execution."

The ticket-in-disguise warning

Watch for a specific pattern: vendors whose public materials use "AI execution layer," "agentic," or "autonomous" language, but whose actual backend, visible once you get past the sales deck into the technical documentation, is a ticket queue with an AI-generated first draft attached. The tell is usually in the status model. If "order status" only has coarse states like "submitted" and "delivered" with no QC scores, no edit-percentage data, no review-gate visibility exposed as structured fields you can query, the system is managing tickets, not exposing execution state as data. A true execution layer should let you pull QC scores and human-edit-percentage analytics programmatically, the way Ollang's platform surfaces AI QC across accuracy, fluency, tone, and cultural fit; human QC annotations; QC score progression and human-edit-percentage analytics as queryable outputs rather than numbers locked inside a PM's dashboard view.

Ask every vendor claiming "AI execution" to show you the raw API response for an in-progress order. If what comes back is a status string and a file link, you're buying a ticketing system with better marketing. If what comes back is structured state, with QC scores, reviewer assignment, edit percentage, and revision history, you're looking at something you can actually build governance and reporting on top of.

The closing argument

Feature checklists persist in procurement because they're easy to fill out and easy to compare in a spreadsheet. Architecture criteria are harder to score because they require reading API documentation instead of a features page, and they require asking vendors to demonstrate rather than describe. But the checklist approach optimizes for the wrong outcome: it rewards vendors for having a feature that technically exists somewhere in their product, regardless of whether your engineering team can ever reach it without a services engagement.

The five criteria here, API completeness, model neutrality, callback support, machine-auth model, and data structure, are the properties that determine whether localization becomes something your systems call the way they call any other service, or remains something your organization routes through a vendor's account manager. Score every vendor against them before you score anything else. The feature list will still be there afterward, and by then it will matter a lot less than you thought.