Why we built Fily

Fily started the way most tools worth using start: with people doing the work, frustrated by the tools available for doing it.

We come from translation. Not from a product team that identified localization as an attractive market — from the side that has to deliver files to clients on a deadline, in fifteen formats, with terminology that has to be right and tags that have to survive. Every platform we evaluated asked us the same thing: adapt your work to our interface. Learn our editor. Configure our workflow. Manage our projects.

And at the end of all that configuration, we still had to do the translation.

The category sells a workflow. Buyers want a result.

This is the observation everything else follows from. A translation management system is software for running a translation operation — assigning people, tracking steps, moving money. It is genuinely useful if running that operation is your business.

But most people who need something translated do not want an operation. They want the file back, correct, in a format their client accepts, with some way to prove it is right. Everything between those two points is overhead the industry has spent twenty years making more elaborate rather than smaller.

So we built the other thing. Upload a file. Get it back translated, with the glossary applied, the tags intact and a report attached. No editor to open, no segments to approve, no project to configure. The workflow does not get better — it gets out of the way.

What we refuse to compromise

Speed is easy. Speed without breaking things is the entire engineering problem. Three commitments shape every decision we make:

• The file you upload is the file you get back. Same format, tags intact, formatting preserved. If Trados would reject what we produce, the job fails rather than ships.
• Your translation memory is yours. Exact matches bypass the AI byte for byte and cost nothing — rate zero, not a discount.
• Your terminology gets enforced, not suggested. If the software knows the term is wrong and knows the right one, handing you a list of violations is not quality assurance.

What we are deliberately not building

We are not a marketplace. We do not want to broker translators, take a cut of their rate, or become the middle layer between you and the people who do your work.

We are not a TMS. We do not manage your vendors, your purchase orders or your invoices to them. Plenty of software does that, and some of it does it well.

We are not another CAT tool. There are good ones, some of them decades old, and a browser clone of a desktop editor is not what this industry was missing.

Saying no to those three is what makes it possible to be excellent at the one thing we do: turning a file into a finished, auditable translation.

AI does volume. People do judgement.

We are not interested in the argument about whether machines will replace translators. In practice the division is obvious: automation is extraordinary at the ninety-five percent that is repetitive, mechanical and rule-bound, and people are irreplaceable for the rest — the ambiguity, the brand voice, the sentence that is technically correct and completely wrong.

The design goal is to make that boundary visible instead of pretending it does not exist. Which is why every job leaves an audit trail: what the pipeline caught, what it fixed, what it flagged for a human, and what a human decided. If someone asks how you know a translation is right, we think you should have an answer that is not “the vendor said so”.

And a human on the other end

Every paying account gets a dedicated Account Manager — a person who knows your formats, your glossary and your deadlines, with a direct line to the engineers. When a workflow does not fit, the answer is usually a new pipeline rather than a support ticket explaining why it cannot be done. Several of the things this product does best started exactly that way.

What this blog is for

Product updates, engineering notes about how things actually work, and opinions about this industry that we are willing to defend. What we ship, and why. No growth-hacking listicles, no vendor jargon, and no claims about features that do not exist yet — when something is on the roadmap we will say roadmap.

If any of this sounds like your problem, the fastest way to evaluate us is not a demo call. Upload one real file — the awkward one — and look at what comes back.