LingoHub: the system whose bills we pay ourselves.

Starting point

Software products ship in several languages, and the text for them is not written inside the product but next to it: in spreadsheets, resource files, email attachments and at the translation agency. For many development teams that is still the state of things. Between a text change in the code and the translated version in the application sit several manual steps, and every one of them can go wrong.

In 2012 we decided to build a product for this — not as a side project, but as a business that has to carry itself. That decision is the reason hemju exists in its current form: it put us in a role that most software suppliers never take on. Since 2012 we have been the customer of our own code.

Why us

In the other case studies, this section explains why the choice fell on us. Here there was no choice: we built it, financed it, sold it and ran it ourselves. There was nobody to pass a problem on to.

That sounds like a detail and it is the whole difference. A supplier never learns which of its decisions comes back in year six — the project was handed over long ago. We paid for every shortcut we ever took, in weekends, in postponed features and in invoices nobody else covered.

What was built

LingoHub is a platform for translation management: it collects text where it is written, brings it together with the translations and delivers it back to where the application needs it. The main architecture decisions and the reasoning behind them:

Connected to the developers’ tools, not to their calendar. Translation becomes part of the normal development workflow — repository integration, API, automation — instead of an approval step at the end. Anything else would have been worked around by the users.

Tenant separation from day one. As a supplier to business customers, the question is not whether somebody checks, but when. Separation of customer data, permission logic and logging were part of the data model from the start, not an afterthought.

Technologies picked for durability, not for novelty. More than once we passed over the interesting option and took the one that will probably still be maintained in eight years and will still have developers available. The cases where we did not stick to that are exactly the ones that cost us money later.

The stack in use: [TECHNOLOGY STACK].

Result

The proof for a product is not its home page, it is how long it has been running. The verifiable figures:

Metric	Status
Founded	2012
Uninterrupted in production	since 2012
Paying customers	[NUMBER]
Supported languages	[NUMBER]
[METRIC: e.g. text segments processed per month]	[VALUE]
[METRIC: e.g. availability in the last calendar year]	[VALUE]
Founders still on board	[NUMBER]

Every figure in this table has to be backed by actual values before publication. We deliberately use no estimates here: the whole positioning rests on our statements being verifiable.

Since then

In the other case studies this is the most important section. Here it covers more than a decade.

Several technology generations. We have migrated major framework versions, changed databases and rebuilt the infrastructure from the ground up — [SPECIFIC MIGRATIONS WITH YEARS]. Every time in live operation, every time with the aim that customers would notice nothing. What we learned: a migration you postpone does not get cheaper. It gets more expensive, and at some point impossible.

The GDPR did not arrive as a project. It arrived as a permanent condition. In 2018 we rebuilt data processing, deletion concepts, processor agreements and documentation. Since then, data protection is part of our architecture and not an appendix at the end of the specification. That change cost [EFFORT] — effort we would partly have saved with a clean data model from the start.

Security as a process. As a supplier to business customers we get audited — by security teams that want to know exactly. [SPECIFIC DETAIL: type and frequency of audits, penetration tests, customer audits. Substantiate this statement before publication or remove it.] You build differently when you know somebody is checking.

AI runs in production here, not in a pilot. Machine translation and AI-assisted quality checking run in live operation at LingoHub, for paying customers. So we know what an AI feature costs per month, where it produces nonsense and how to catch that before it reaches the customer. Specifically: [DESCRIPTION OF THE AI FEATURES, YEAR INTRODUCED, MODEL OPERATION]. That is different knowledge from a pilot project that ends after the presentation.

Scaling never came at a convenient moment. We have had load peaks where architecture decisions from the year before came straight back at us. [SPECIFIC INCIDENT, PERIOD, MEASURE TAKEN].

Technical debt is compound interest. We have measured what deferred clean-up work costs after five years. That is why every one of our operations contracts reserves a fixed share for structure, tests and clean-up — not out of idealism, but because we know the invoice.

The same team. The people who built LingoHub still develop it today. At the same time, the code has to be readable by people who were not with us in 2012. That is the sharpest maintainability test we know, and it runs here permanently.

Client quote

Because LingoHub is our own product, there is no quote here about us as a supplier, but one from somebody who has used the platform for years.

‘[QUOTE FROM A LINGOHUB CUSTOMER — approved, verbatim, stating how long they have been using it.]’

[NAME] · [ROLE], [COMPANY] · Customer since [YEAR]

[Photo: [FILENAME], obtain written approval.]

Why this matters for your project

You can judge a supplier by what it promises. Or by what it has had to live through itself.

Since 2012 we have had to live with every decision we made. When we tell you that a technology choice will catch up with you in year six, or that a system without an operating concept is not finished, that is not an opinion from a textbook. It is an invoice we have paid.