About me

Professionally, I work with technology, virtualisation, integration and architecture. Even though my working day already involves plenty of technical work, I often spend evenings and weekends on my own projects. You could call it my favourite hobby. One of many.

Other people ride motorbikes, go fishing or work on old cars. I look forward to immersing myself in a technical problem, understanding how things connect and building something that did not exist before.

That might be my own software, a new automation for my smart home, an improvement to my network or simply a service I want to try out. In recent years, another major playground has emerged: artificial intelligence and the question of what I can create with it and where it can offer me real value.

Spoiler: it has fundamentally changed the way I develop projects.

How it all began

My first computer was a Commodore 16 with a Datasette. I was eleven years old, and although its capabilities seem modest today, it opened up an entirely new world for me.

Next came a C64 with a floppy disk drive. That was when I started typing in BASIC listings spanning several pages from 64’er magazine. Line by line, a game or a small application took shape on the screen — provided I had not made a typo somewhere.

It could be tedious, but it was also fascinating: printed text became something I could run, try out and change. That was probably where the enthusiasm that still drives me today began — creating something of my own from an idea and many individual building blocks.

Later came the Amiga 500. What fascinated me most about it was the demoscene. What developers and artists managed to squeeze out of that limited hardware was incredible: graphics, animation and music, with some intros fitting into just a few kilobytes.

Those demos were not just technically impressive. Their creativity and atmosphere were far ahead of their time. They showed me that good results do not necessarily require unlimited resources. What matters is how well you understand a system and how creatively you work within its limits.

At the same time, I discovered games that fascinated me as much for their atmosphere as for their gameplay. Adventures such as Maniac Mansion, Zak McKracken, Indiana Jones and Monkey Island felt like interactive worlds.

With each new generation, graphics and sound improved, characters became more vivid and stories richer. The combination of images, music, dialogue and interaction created an atmosphere that stayed with me for weeks.

Looking back, what fascinated me then was probably the same thing that excites me about good products today: no single technical achievement creates the experience. It only emerges when many different elements fit together carefully and feel like a coherent whole to the person using them.

After the Amiga came my first PC, a 486 DX running at what seemed an incredible 33 MHz. And then came the internet.

The first time I dialled in with a 33.6 kbit/s modem, accompanied by that unmistakable whistling and static, it felt as though a door to an entirely new world had opened. Suddenly, my computer was no longer alone. It was connected to other computers, information and people.

By today’s standards, everything was slow, cumbersome and technically limited. Back then, I simply thought it was fantastic.

From developer to architect

That early enthusiasm eventually became my profession. I started as an application developer, initially focusing on translating business requirements into working software.

I learned numerous programming languages and spent much of my free time teaching myself things that many other people did not yet know what to make of. I had a real thirst for knowledge.

Over time, the questions grew bigger. No longer just: how do I implement this feature? But also: how does the result fit into the existing environment? Which systems, interfaces and people are affected? How can a solution be operated securely, developed further and kept manageable for years to come?

I gradually took on responsibilities beyond software development — from networking, systems integration and technical operations to architecture. My focus shifted increasingly from individual programs to the interaction of entire systems.

Today, I work as a Solution Architect in a global corporation. I have never left application development behind. It remains the foundation of how I think. I understand the developer’s perspective, while also considering integration, security, operations, users and the ability to adapt over the long term.

All these perspectives come together again in my personal projects — with one important difference: here, I decide which idea to pursue, which technologies to try and how deeply I want to explore a problem.

Unwinding starts with a problem

When I see that something could be clearer, more robust or simply better, it rarely leaves me alone. A small idea can quickly become a real project — complete with architecture, interface, operations, documentation and all the decisions in between.

This mostly happens at weekends, sometimes in the evening after work. I do not see it as an extension of my working day. It is how I unwind.

I can spend hours working on an automation in my smart home, analysing my network, running services in Docker or developing my own application. Not every project has to become a product or serve a purpose that makes sense to other people. Sometimes, one question is enough: can I build this better, more simply or even build it myself at all?

That is exactly where the enjoyment lies for me. I immerse myself in a problem, discover connections and experience the moment when many loose pieces become something that works. I simply enjoy creating something of my own.

These days, I am interested in more than an individual piece of code. It may have been a little different in the past: I could spend forever on a single line, just to make the code more elegant or shorter.

Now I want to understand the entire system: where are its limits and dependencies? Where does the architecture hold up — and where does it stop doing so? How can a solution be extended later without everything falling apart?

A solution only feels right to me when its parts do more than work: they fit together.

Between engineer and product thinker

I enjoy thinking in architectures. But architecture is never an end in itself. It has to serve a product, remain understandable and support the person using it.

That is why I can spend just as much time on a domain boundary as on a visually distracting button, a misleading term or a flow that is technically correct but still does not feel right.

Backend, frontend, database, security and operations are not separate worlds to me. Together, they reveal how carefully a system has been thought through.

I value clear models, sound decisions and software that does not lose its elegance when it encounters its first real requirement. At the same time, I know that good systems rarely emerge on the first attempt. They are questioned, discarded, simplified and sometimes rethought completely.

Automation as a common thread

Automation has been part of my life for a long time. I am interested not only in whether a task can be solved technically, but also in whether a system can take it on independently, reliably and transparently in the future.

For me, good automation is not about doing as much as possible. It should take recurring work off my hands, follow clear rules and remain controllable. I want to understand what is happening in the background, be able to trace decisions and retain control over the system at all times.

Artificial intelligence opens up entirely new possibilities here. Systems can do more than execute fixed workflows. They can understand language and content, recognise connections and handle situations that cannot be fully described in advance through fixed rules.

To me, however, that does not mean everything suddenly needs AI.

As deterministic as possible

Despite my enthusiasm for artificial intelligence, I do not want to solve every problem with AI.

Whenever something can be modelled reliably with clear rules, I prefer a deterministic implementation. Such processes are much faster, reproducible and understandable. Identical inputs produce identical results — and when something goes wrong, the cause can be investigated directly.

I only use AI where it offers real value: when language needs to be understood, unstructured information organised, connections recognised or decisions prepared that cannot sensibly be translated into rigid rules.

The stable core of an application remains as conventional as possible. Data storage, permissions, validation, states and critical workflows should not depend on a language model’s spontaneous interpretation. AI takes on the specific tasks that need its particular strengths — embedded in a system that checks its results, sets boundaries and keeps it controllable.

Where traditional software is the better solution, I would not use AI.

To me, modern software development is not about connecting as many features as possible to a model. It means choosing the right tool for each problem.

As deterministic as possible. As much AI as necessary.

AI — but under my own control wherever possible

Many of today’s visible AI projects take a different approach. Videos and showcases demonstrate the impressive results that can be achieved with the most capable frontier models in the cloud.

That is exciting and often inspiring. But I am interested in a different question:

What happens when an impressive demonstration needs to become an application I would trust with my own data?

For me, that is where the real challenge begins.

I do not just want to demonstrate AI. I want to integrate it into systems that provide lasting value in everyday life: applications that search my documents, process personal information, automate tasks or work as an intelligent service or agent within my own network.

I take a local-first approach. Wherever it makes practical sense, models, data and processing should stay on my own hardware. The cloud can be a tool, but it should not automatically become a prerequisite for every feature.

This is not a blanket rejection of the cloud. Powerful cloud models already help me think, develop and review. In the finished system, however, I want to make a conscious choice about which data leaves my own network — and which does not.

I want to build applications that still have value when no personal documents, conversations or internal information are sent to an external service. Systems whose data flows I know, whose behaviour I can understand and over which I retain control.

Technically, that is often harder than a quick cloud showcase. Local models are smaller, available hardware is limited and many tasks require more architecture, optimisation and infrastructure of my own.

That is precisely what makes these projects interesting to me.

I am fascinated by more than what the largest available model can do. I want to know how much can be achieved on my own hardware through good architecture, specialised models, automation and the right division of tasks.

Agents as a new way to do more

I am particularly fascinated by the idea of orchestrating several specialised agents, assigning them different tasks and bringing their results together into a coherent whole.

One agent can investigate a question, another work on implementation and a third check for potential weaknesses, errors or contradictions. This is not about handing responsibility over to AI. It is about breaking tasks down sensibly and combining different capabilities with purpose.

For me, this is an enormous boost. On some tasks, I feel I can work ten times faster today — perhaps even faster than that.

The real gain is not in generating as much code as possible in less time. I can try ideas earlier, explore several approaches, spot mistakes sooner and pursue projects in a depth that would otherwise be almost impossible in my limited free time.

To me, AI is not a toy where you write a prompt and receive a finished product. That may work in individual cases. My experience of AI, however, is as a new tool that can improve and accelerate many steps — and increasingly as a real thinking partner.

This only works if you set the direction yourself: clarify requirements, break tasks down sensibly, question results and refuse to simply accept contradictions. A plausible answer only becomes a sound solution through scrutiny, context and further development.

The speed comes from AI. Direction, judgement, data and responsibility should remain with me as far as possible.

Why Operus exists

My evening and weekend projects constantly produce insights that are no longer visible in the finished result. They live in failed attempts, discussions with AI, architectural decisions and those small moments when a complicated solution suddenly becomes clear.

Operus is my attempt to make this work visible. Not as a carefully staged professional portfolio, not as a collection of interchangeable tutorials and not as a platform for perfection presented after the fact.

It is my hobby — and I would like to share it with you.

Operus is my technical journal about systems that actually take shape in my free time: with their ideas, decisions, detours and occasional fresh starts.

I do not just want to present finished results. I am interested in how an idea becomes a project, why certain decisions held up, which alternatives did not work and what I would do differently next time.

What you can expect here

I write about technical topics, software development, architecture, smart homes, networks, automation, artificial intelligence and the creation of my own products. Above all, I also write about the decisions in between.

The topics will vary, but they share a common origin: the enjoyment of understanding technology, connecting things and building something of my own from them.

Operus is meant to be neither loud nor arbitrary. I want to record things with substance — honestly enough to discuss wrong turns, and concretely enough for others to take something useful into their own projects.

If one thought stays with me, it is this:

Good systems do not emerge from using as much technology as possible. They emerge when curiosity, experience and care work on the same problem for long enough.

You now know quite a lot about me and the motivation behind Operus. I look forward to sharing the projects, results and experiences that grow out of this enthusiasm.

Perhaps other formats will follow later. But the focus will remain on what mattered to me from the beginning: creating things, sharing my experiences honestly and bringing others along on the journey.

Enjoy reading!

Oliver