Systems that run.

Reference pages usually show whatever looks best: the freshest project, the prettiest interface, the sign-off handshake. But the moment at which you can actually judge whether software was built well is not the sign-off. It comes three to five years later.

Why this selection

We show systems that have been running for years, not the ones we finished last. That is a deliberate choice and it costs us gloss: a system from [YEAR] no longer looks like a design from yesterday. In exchange, it lets you check something that no screenshot shows.

What interests us is the time after go-live. Was the system developed further, or only kept alive? How often did the technology have to be brought up to date? What does a change cost today compared with the first year? Who touched the system last — and did that person need weeks to read into it first?

We can answer exactly these questions, because we have been going through the same exercise on our own product since 2012. That is why LingoHub is here as the third case study: not as advertising for the product, but as the evidence we have kept longest.

What every case study contains

Every case study follows the same six-part structure. Always in this order, always complete:

1. Starting point — What was the problem before we arrived? With numbers instead of adjectives wherever it can be quantified.
2. Why us — Why did the choice fall on us? Including when the reason was unspectacular.
3. What was built — Which system was created, which architecture decisions were taken and for what reason. Including the decisions we would take differently today.
4. Result — The measurable change, with a reference base and a date of measurement. A percentage without a basis for comparison is not a number, it is a claim.
5. Since then — What happened in the years afterwards: further development, technology changes, incidents and how they were handled. This is the most important section. It is also why this page looks different from most reference pages — anyone who hands a system over at go-live and moves on simply cannot write it.
6. Client quote — with name, role and photo, approved by the person quoted.

When a client cannot be named

That is the normal case, not the exception — especially in public administration and in safety-relevant manufacturing. An anonymised case study still works, but only with concrete detail. ‘An Upper Austrian machine builder with 240 employees’ is usable. ‘A leading industrial company’ is worthless, and we would not write it either.

What is true in every case: if you talk to us about a specific project, we put you in touch with a reference client in a comparable situation. A phone call with someone who has worked with us for years says more than any page we write about ourselves.