Why I build the way I build.

My first project was a migration to a new platform. I quickly learned what so-called vendor lock-in does: it weaves your core infrastructure together with one large provider. Because of provider-specific tools, you cannot simply pack up your things and leave. The whole system has to be unwoven first. In the first years this is usually not a problem, but in a fast-changing world you can suddenly find yourself running on outdated technology. Migrations can be painful, take years, and turn out incredibly expensive.

On paper a tool can meet every requirement and come well argued by consultancy firms, but it often misses the reality an engineer actually deals with. At that level different interests are at play, ones that do not always match how users, developers, and even the platform's own architects handle it in practice.

A few years ago there was no alternative, but by now an enormous amount has been built in the open-source world, and more and more standards are being picked up by established players. Developments move step by step, but it is clear where this is heading: open standards, workable and interchangeable.

The path runs from company-specific software toward modules that can be added or removed depending on what the company needs. The benefits are clear: developers increasingly converge on the same open tools, which makes it easier to find the right expertise. And because it is open source, software stays stable and maintained for years, guaranteed.

I try to carry this development through to its conclusion. The building blocks of a data infrastructure should be simple to use and easy to swap out. Every part of the platform should be migratable within a day.