Compare
Cloud translation services sell API calls. You need a finished document.
These services are infrastructure: reliable, well-documented, and metered by volume. That model is a good fit for text. It is a poor fit for a document workflow.
What it is good at
Reliability and scale are the strength. These are infrastructure services built to handle volume, and they do it.
Integration is well documented. If your need is text translation inside an application, these services are a reasonable answer.
They are general-purpose by design. Document layout, page-level decisions and delivery quality are outside what a general-purpose translation service is built to handle.
Where the document itself is left to you
These are the gaps our pipeline exists to fill. They are about the file, not about the tool.
You own the reassembly
A service returns translated text. Getting that text back into the document it came from is your engineering problem, and it is a different problem per format.
No page-level routing
Mixed documents need decisions per page. A text service has no view of pages at all.
Scanned content is out of scope
Recognition, layout understanding and translation have to be joined up for a scanned page to come back as a usable document.
Quality is measured in characters, not in delivery
The commercial model is per-character consumption. Nothing in it is oriented around whether the delivered document is correct.
Repair means re-sending
There is no concept of marking one region and reprocessing it.
Capability comparison
Categories, not vendors. We do not publish anyone's pricing, including our own.
| Row label | Us | Raw MT / cloud translation APIs | TMS platforms |
|---|---|---|---|
| Multilingual | Configured to your markets | A fixed list | A fixed list |
| Format preservation | Layout written back in place | Text or a rough file | Not an engine |
| Per-page processing plan | Each page routed on its own | One call, no quality control | Manual workflow |
| Multimodal input | Five source classes, five paths | Mostly text only | No |
| What you receive | Finished files | A block of translated text | Process management |
| Who owns the quality | Us | You | You |
How this sits next to a cloud MT service
Different layer of the stack, and both can be present.
If you are building text translation into an application, a cloud translation service is a reasonable choice and we are not arguing otherwise.
Where documents are involved, the reassembly work is what costs you — and that is the work our pipeline removes. Your system submits the file; a finished document comes back.
Some teams use both: a cloud service for interactive text, our pipeline for document deliveries. The split follows content type.
Questions
Are you a cloud translation API?
No. We are a document pipeline. The difference is what comes back: a cloud service returns translated text; we return the finished document with the layout intact.
Do you resell a cloud translation service?
No. The pipeline is built in-house, including the parts that decide how each page is processed and the quality check that runs before delivery.
What about scanned documents?
They go down the optical recognition path, and in a mixed PDF that decision is made page by page rather than for the whole file.
How does your commercial model differ?
We do not publish prices, for us or for anyone else. What a document costs to process depends on what is in it — that is a scoping conversation, not a rate card.
Can we keep using our cloud service alongside this?
Yes, and many teams do. The usual split is by content type: text interactions go one way, document deliveries the other.
Send us a document a text service cannot finish.
The reassembly step is where the cost hides. One real file will show you what removing it is worth.
- No signup, no self-service portal — you send a file, we run it.
- You get the finished document back, not a screenshot of one.
- If it is not good enough, you have lost nothing.