The work I do
I started my software career with public-sector, GIS, and e-government systems. Since then, I have built telemetry services for energy plants, retail and ERP products, multi-tenant SaaS platforms, and regulated integrations that exchange documents through Peppol across Europe.
I do not see myself as someone who only draws a solution. I still build services in Java and .NET, inspect Kafka flows and data models, review code, and join the team when a production problem needs to be traced.
How I make decisions
- I first understand the context and the real bottleneck. A monolith or microservices is never a goal on its own.
- I write down service boundaries, data ownership, failure cases, and the trade-offs we accept.
- This includes AI-generated code: an engineer must understand and own every line that reaches production.
Staying close to production
The validity of an architectural decision is not determined by diagrams or design meetings alone; real traffic, network failures, data inconsistencies, and audits reveal the outcome. I therefore treat observability, troubleshooting, and production feedback as a continuation of design, and closely follow how the systems I build behave under real conditions.
How I work with AI
I use AI not merely as an assistant, but as an execution layer that I direct. I define the problem, make the architectural decisions, and set the quality boundaries; AI carries out repetitive implementation, analysis, and validation work. This keeps thinking and engineering judgment with the human while scaling production capacity through AI.
Why I write
Rather than publishing lists of “right technologies,” I write about the context in which technical decisions are made and the results they produce in production. Through sovereign cell architecture, monolith-to-cloud-native transitions, domain values in distributed systems, and real failure scenarios, I try to show not only what works, but why it works and where it falls short.