Hi, I'm Eugen.

My full name is Yauhen Yakimovich. I have been building software professionally since 1999 and working in Switzerland since 2011.

I am a software engineer, architect and former CTO. Over the years I have worked across research, startups, banking and insurance, usually somewhere around the point where software stops being a prototype and has to work reliably in the real world.

These days my work is mostly around cloud and platform engineering, security, SRE, data and AI. I still like being hands-on. Architecture is much more useful when you know what it takes to build, deploy, operate and debug the thing you are designing.

If you are here for the professional version, there are two:

Curriculum vitae: current CV — a concise 3-page professional profile, or the full CV — the complete career record.

My diplomas, including English translations, are also here. Work certificates are available on request.

how I got here

I was interested in electronics and computers long before I had a job doing either.

As a teenager I built and experimented with radio and electronic devices, assembled PCs. There was no Internet access where I grew up, so I ran my own bulletin board system (BBS), COPCOM BBS, in Minsk¹, and connected to other systems through FidoNet.

A few years later, in 2002, a friend and I co-founded IRC.BY. It grew into the first Belarusian IRC network and one of the country's popular online communities.²

At its peak, IRC.BY connected around 50-60 IRC servers in a spanning-tree topology. We had roughly 60,000 registered users and around 10,000 online concurrently.

Looking back, it was already a distributed production system: independent servers, unreliable links, routing, operators, abuse, availability problems and a community that expected the whole thing to simply keep working. We did not call any of that SRE.

I later studied software engineering, computer science and mathematics. My first professional software work was in 1999, initially around databases, backend systems and web applications.

From 2008 to 2011 I lived and worked in Germany. I first moved to Bremen for an Integrated PhD programme in mathematics and computer science at Jacobs University. After leaving academia in 2009, I moved fully into industry, working between Berlin and Hannover. This included freelance and agency work on e-commerce systems, including projects connected with Zalando and Brands for Friends, followed by a full-time software engineering role at Symmetrics GmbH in Hannover from September 2009 until 2011.

The work covered e-commerce platforms, backend services and general software development in PHP, Java and JavaScript, often around Magento and related systems. It was also where I first worked with AWS, around 2009-2010, when public cloud infrastructure was still a relatively new part of mainstream software engineering. In September 2011 I moved to Switzerland, where I have lived and worked since.

Switzerland is where most of the rest of it happened: distributed systems, scientific computing, machine learning, startups, cloud platforms, security and large-scale production infrastructure.

The technologies changed considerably. The underlying problems did not change quite as much.

science, supercomputers and cloud

From 2011 to 2016 I worked at the University of Zurich.

It was an unusually good place to learn what happens when problems become bigger than one machine. I worked with HPC and HTC clusters, OpenStack, distributed storage, Spark, scientific workflows, image processing and machine learning.

I helped build private-cloud and large-scale data infrastructure for research while also writing software and developing algorithms. Some of that work led to scientific publications.

The environment ranged from virtual machines and storage systems to large computing clusters and image-based biology. I worked with systems such as SLURM and Platform LSF, the ETH Zurich Brutus cluster, OpenStack, KVM, VMware, GlusterFS, Spark and scientific workflow tooling.

It was a mixture of systems engineering and science that still influences how I approach engineering today: measure things, understand the system and test assumptions.

building companies and products

After UZH I moved into startups.

At PriceHubble I was CTO during the company's early years. We took a real-estate valuation product from an early MVP to a production B2B platform for real-estate, banking and insurance customers.

I worked across the stack: data modelling, Spark and Luigi pipelines, machine-learning training and validation, APIs, Kubernetes, Google Cloud and the infrastructure needed to run it all. I also worked closely with the front-end team building the user-facing applications: GeoData integration, data visualisation, Angular and the Mapbox-based mapping application.

That was before “MLOps” became a convenient label for the problem. We simply had models that needed to be trained, tested, packaged, deployed and kept working in production.

I also learned a lot about what being a CTO actually means in a small company. Sometimes it is architecture. Sometimes it is hiring or product decisions. Sometimes it means debugging production yourself because there is nobody else to call.

Later I co-founded Crypto Real Estate AG in Zug.

We worked at the intersection of real estate, software and blockchain: KYC onboarding, investment-management software, Ethereum smart contracts and a security-token architecture.

I designed the architecture behind several of those systems and led teams working on the platform, website and smart-contract components. I also had the opportunity to work directly through regulatory classification questions with FINMA.

Some of that period was very much a product of the crypto years. What stayed with me was the more interesting problem: how to take a new technology and turn it into something that solves an actual business problem.

production systems

Since 2019, most of my work has been in large regulated environments.

At Swiss Re I spent five years working across security architecture, DevSecOps and cloud engineering for a mission-critical Azure platform.

That included Kubernetes, Terraform, Microsoft Entra ID, workload identities, mTLS, secure CI/CD, Azure Policy, Databricks, Azure Data Factory, observability, high availability, disaster recovery and production operations.

A large part of the job was not merely designing systems but making them survivable: understanding failure modes, securing identities and communication paths, establishing operational standards and making sure somebody could actually understand the system at three in the morning when something went wrong.

At UBS I worked as Lead Cloud Architect on moving a heterogeneous wealth-management application landscape from on-premise infrastructure to Microsoft Azure.

That included AKS, application security and identity, CI/CD, OpenShift, IBM MQ and near-real-time data processing with Databricks and Azure Data Factory.

I am currently working with Allianz on PostgreSQL modernisation in Azure.

My work there includes Azure Database for PostgreSQL Flexible Server, automated permission and role governance, Microsoft Entra ID integration, migration standards, CI/CD, observability, high availability and operational readiness.

I designed a permission-management framework that treats database access as infrastructure and policy rather than a collection of manually maintained grants. I have also designed an internal AI-routing API: a controlled layer between enterprise applications and different LLM and model providers, with authentication, quotas, policy enforcement, fallback, streaming and observability.

Different companies, different technology stacks, but much of the job is the same: make complicated systems understandable, secure and dependable.

AI, agents and the wiring fringe

What interests me about AI is not only the model itself, but what happens when models start interacting with tools, data and real systems.

Security is always das Endspiel, not a separate checkbox. And even that is not enough: if security happens last, you have already lost.

With normal services, we know much of the playbook: TLS, PKI, workload identities, secrets, network boundaries and least privilege. With agents, suddenly there are more boxes where strings go in and strings come out, they all talk to each other, and the interesting security problem is no longer only inside the box but at the wiring fringe.

You cannot fully trust what an agent will do, and you definitely cannot just hand it secrets. I would rather build the system so that the agent never has unnecessary access in the first place: scoped identities, explicit capabilities, controlled tool access, auditability and observability.

What also makes this interesting is that text is no longer just text. It can be data, instructions, context or all three at once. An agent can consume something written by an untrusted third party and use it while deciding what to do next. Once it can act on behalf of a user or another system, this becomes an infrastructure and security problem very quickly.

That is the part I find genuinely fascinating.

There is also a semantics side to it. For most of my career, software worked by forcing the world into structures we had defined in advance. Now we suddenly have components that can operate on intent and meaning, and that opens up new possibilities for automation, interfaces and engineering workflows.

HyperMarkdown grew partly out of that line of thinking. It is ordinary Markdown plus wiki-style links and transclusion, so a folder of .md files stops being a pile of isolated documents and becomes a local knowledge base: you name another document, or a single block inside one, and you write a definition once and embed it wherever it is needed.

The result is a knowledge graph that is still plain text: readable, diffable and version-controlled for humans, and structured enough for agents to traverse and resolve on their own.

We are still early. But we can already be dangerously efficient.

That is why I find this space so interesting: not only what AI can do, but how to make these systems useful without giving away control.

what I care about

I like difficult technical problems, but I am not particularly interested in complexity for its own sake.

A technology earns its place when it makes a system simpler, safer, faster or more reliable, or when it enables something genuinely useful.

I have seen enough technology cycles to be enthusiastic about new ideas without assuming that every new idea deserves to survive.

I care about reliability, security and engineering that works outside a presentation. I like automation, clear interfaces, observable systems and architectures that people can actually operate.

I also still write code.

I experiment with programming languages, distributed systems, cryptography, data and AI, and occasionally publish things when I think an idea is worth writing down.

There is probably a common thread through all of this: I am curious, I like understanding how things work, and when I find something unnecessarily complicated or broken, my first instinct is usually to try to fix it.

Next to GitHub projects, some of my selected projects are mentioned on this homepage.

Liebe Grüsse,
Eugen