Translation is the easy part — review and staleness are the product

We built a translation service for CompanyGraph and learned the lesson the way you usually do: by building the wrong thing first. The plan was a translation layer. The work that mattered turned out not to be translation at all.

The translate call took about a day. You hand text to a provider — Google, DeepL, a language model — and fluent target-language text comes back. That part is solved, and solved well; renting it is the right call. Whatever craft remains — domain terms, tone, a legal or medical phrase that's fluent and wrong — lives around the call, not in it. We had English flowing into other languages by the afternoon, and for about a week it felt like the product was nearly done.

It wasn't. Here is the deflating part up front, because it's the most useful thing in this article: an on-the-fly translation layer is rarely a product on its own. The translate call is a commodity. The two things that are genuinely hard — deciding when a machine translation is good enough to ship, and noticing when a translation has silently gone wrong because the source text changed — are the only durable value, and they almost always live beside a content product rather than standing up as their own business. Put from your side of the table: you may think you're buying translation, but what you actually need to own is review, source lineage, and stale-content detection. The rest of this is us earning that verdict.

The two things that aren't the translate call

The honest unit here isn't the call — it's the whole life of a translated string:

Source text changes → it gets sent for translation → a result comes back → someone or something decides whether that result is good enough → it goes live in each language → and later, when the source changes again, every translation of it is now suspect and has to be found and redone. The translate call is one step in the middle. The two steps in italics are the product, and neither of them is the API.

Call them review and staleness. They're worth taking one at a time, because each looks small until you build it and each is where the real time goes.

Review: validate once, escalate on a bounded ladder, then hand to a person

A machine translation is usually good. Sometimes it's wrong in a way the machine can't see — a term of art rendered literally, a tone that's off, a sentence that's fluent and incorrect. The naive design treats the endpoint as a function that always returns the right answer. The honest one accepts that it sometimes doesn't, and decides in advance what happens then.

Here is what CompanyGraph's service actually does, because the mechanism is the point. A translation is checked once. If it's good enough, it's kept. If it isn't, it goes through a bounded escalation ladder: try a cheaper model, then a stronger one, then re-roll once more — and every attempt is a fresh translation, not a correction of the last one. We tried the obvious alternative — a "please fix your previous answer" repair prompt — and deliberately rejected it; feeding the model its own flawed output to patch produced worse results than asking again from scratch. Each attempt is logged. And if the result still isn't good enough after the ladder runs out, it isn't quietly accepted. It's flagged for a human — a state we call AdminReviewRequired — and it waits in a review queue for a person to look at it.

That shape matters more than the specific models. Validate once, escalate on a path with a visible end, then stop and hand the decision to a person — never silently retry forever. A loop that keeps retrying until it gets a pass doesn't make translation better; it hides the failure rate and ships whatever finally slipped through. (This is the one earned exception to validate once — escalation with a logged, bounded end is not the same as a hidden retry. The capability note that pairs with this one, renting a model you don't own while keeping the record you do, makes that distinction in full.)

There's an editorial half to review that's easy to miss until it bites. Translation in CompanyGraph is an action you take when you mean to, not a thing that happens on a timer. We removed scheduled, batch auto-translation on purpose. And a re-run never overwrites a translation a human has already edited — if someone fixed a string by hand, the machine leaves it alone next time. Without those two rules, an automatic pass quietly stomps the careful human work that was the whole reason you had a review queue. Review isn't just catching bad translations; it's protecting the good ones a person already approved.

Staleness: the failure no one sees until a customer does

Now the harder one, and the one that doesn't show up in any demo.

You translate a page into six languages. It looks finished. Three weeks later someone edits the English source — fixes a price, changes a sentence, adds a paragraph. The English is now correct. The other six languages are now wrong, and nothing told you. They still render, they're still fluent, they still look done. They're describing the old version of the truth. This is staleness, and it is silent by construction: a stale translation has no error state, no failed request, no log line. It just sits there being confidently out of date.

Detecting it is harder than any single translate call. The product has to know, for every piece of translated text, which version of the source produced it, notice when the source has moved past that version, and re-queue exactly the translations that went stale — without re-translating the thousands that didn't, because that wastes money and tramples human edits. Doing that well means tracking the lineage of every string and reasoning about change, which is real engineering. The translate call has none of that. It's stateless and it's done in a day. The staleness machine is stateful, it's the thing you maintain forever, and it's where a translation product actually lives.

What it rides on — and why that's the tell

When we built this, almost none of the surrounding work was new. The translation service leans on modules that were already running under CompanyGraph: the translation capability itself, a background-jobs runner to do the work off the request path, an admin to be the review queue, and a logger so every attempt and escalation leaves a trace you can read later. We didn't build accounts, jobs, an admin, or logging for translation. We pointed one new capability at a foundation that already carried the rest. That's checkable — CompanyGraph runs in production and you can see the seams.

That dependency list is also the tell about the verdict. Look at what review and staleness attach to: a body of content that changes over time, owned by someone who cares which version is live in each language. They aren't free-floating services you sell to strangers. They're properties of a content product. The review queue reviews your content; the staleness detector watches your source. Lift them away from the thing being translated and there's nothing left to be careful about — just a translate call, which everyone already has.

What you'd own, and what you'd rent

If you did chase this as a product, the boundary is the same one that holds for any rented capability. The translation engine stays external — you're renting fluency, and owning a translation model is a different company, the way owning a payment network or a diffusion model is. What has to be yours is everything that gives the translation meaning over time: the source-of-truth text and its version history, the verdict on each translation, the human edits, and the record of which model produced what, when. Keep those local and the provider becomes a part you can swap when a better or cheaper one appears. Let the provider's dashboard be your only record and you don't have a translation product — you have a thin pass-through in front of a commodity, and so does everyone else.

The verdict

So: rarely a standalone SaaS. Not because translation is hard — because it's easy, and the easy part is the only part a pure translation product would sell. The durable work is the review workflow and the staleness detector, and those earn their keep attached to a content product that has a reason to be right in more than one language. A documentation platform, a marketplace with international listings, a publisher — translation is a feature that makes the core product worth more, run beside it, sharing the same accounts and admin and jobs and logs.

That's not a small thing to be. It's a clarifying one. It tells you not to spend a quarter building billing and onboarding for a standalone translation SaaS, and instead to build the review-and-staleness layer beside the content product where it belongs — on a base that already carries the jobs, the admin, and the logging, the way ours did. If you've got a content product that needs to be right in more than one language and you want the translate-review-staleness loop running on a foundation that already has the rest, the next sensible step is to see what the foundation already carries.