Back in the Open: 25 Years Building Systems That Cannot Fail

For the past ten years I have been essentially invisible. No conference talks, no blog posts, no social media presence to speak of. I was heads-down, working remotely for an American company, architecting and building one of the largest telemedicine platforms in the world. It was deeply rewarding work — and entirely behind closed doors.

Today I’m stepping back into the open, and I want to explain why.

A career shaped by failure — the kind that kills

I have been a professional in the technology industry for over 25 years, almost always at the intersection of technology and healthcare. The first system whose development I led was an emergency dispatch center — the kind of system where a software failure doesn’t mean a lost shopping cart or a retry button. It means someone doesn’t get the ambulance in time.

That experience left an indelible mark on how I think about software. It taught me that reliability is not a feature you add at the end. It is the foundation you build on, or you build on sand.

Ever since, I have been drawn to high-availability, high-criticality systems — platforms where “five nines” isn’t a marketing term but a genuine operational requirement.

The road less traveled: from manager to architect

My career path has been, admittedly, the opposite of the usual trajectory. After spending half of my professional life as a manager and executive, I made the deliberate decision to become a software architect and hands-on developer. It seemed like the only way to truly put my ideas into practice — to stop drawing boxes on whiteboards and start building the systems I believed were possible.

In a similar contrarian move, I left a secure position in public administration to start my own company. The public sector was suffocating me. I needed to build things, not manage bureaucracies.

Why now? The NetKubes story

During those years of quiet, focused work, I built something I believe is genuinely valuable: a distributed application development platform, first Netcomposer and now evolving into NetKubes. It was born out of necessity — the backbone of a telemedicine system serving hundreds of thousands of medical devices — and refined through years of production pressure.

I have now decided to release NetKubes as open source, starting with Malla, its core framework for distributed services.

Why open source it? Because I believe this technology deserves to be seen. It can help teams build production-grade distributed systems without reinventing the wheel — the same wheel I’ve been refining for over a decade. And because open source is not a one-way street: the platform can benefit just as much from community contributions and fresh perspectives.

The 80/20 problem in software

Software development is, at its core, a problem of drawing lines in the right places. Build something too generic and it takes forever to adapt to real-world needs. Build something too specific and it’s inflexible, limited, brittle.

My intuition — backed by years of building production systems — is that more than 80% of any realistic software project is common ground: data storage, security, monitoring, tracing, communications, API management, service discovery, kubernetes deployment and management… And yet, it is extraordinarily difficult to draw those lines in the right places, to create the right abstractions that are genuinely useful without becoming a cage.

First with Netcomposer, and now with NetKubes, I believe I have found a way to put those lines where they belong. A platform where building a complex distributed system requires roughly 20% of the effort it would otherwise take — not by hiding complexity, but by solving the common problems correctly so you can focus on what makes your project unique.

The quiet power of the BEAM

None of this would be possible without Erlang and Elixir. The BEAM virtual machine is, without exaggeration, one of the most underappreciated pieces of technology in our industry.

Erlang was designed over 30 years ago to build telephone switches that could never go down. The ideas it introduced — lightweight processes, supervision trees, message passing, hot code reloading, “let it crash” — are not just still valid today. They are more relevant than ever, in a world increasingly built on distributed, concurrent, always-on systems.

Then Elixir came along and made everything more comfortable, more elegant. It brought the tooling, documentation, and community that Erlang had always lacked. Every once in a while I wonder how it is possible that these technologies are not used daily by the majority of software professionals. If you care about reliability, concurrency, and maintainability, there is simply nothing else like them.

The AI catalyst

Curiously, the trigger for going public now has been AI. In two very different ways.

On one hand, without AI assistance I could not have produced the documentation, tests, and content at the quality level I wanted, in the time I had available. Building a platform, a website, writing documentation, creating comprehensive test suites — as a solo founder, husband and father of three, the bandwidth simply wasn’t there. AI changed that equation dramatically.

On the other hand, while I remain fascinated by the evolution of AI in software development, I do not believe it is yet capable of building a platform like NetKubes from scratch — the kind of deeply architectural, distributed systems work that requires years of accumulated judgment about where to put those lines. What AI can do, brilliantly, is help any team (or individual) build on top of such a platform, creating high-availability, production-quality systems in a fraction of the time.

This is, I think, the real story of AI in software engineering right now: it is a phenomenal force multiplier, but it multiplies what you bring to the table. A solid foundation matters more than ever.

What comes next

This blog, this website, and the NetKubes project are my way of stepping back into the community after a long absence. I plan to write about the things I know best: building systems that don’t fail, distributed architecture on the BEAM, the art of drawing the right lines in software design, and the practical lessons learned from running critical healthcare infrastructure.

If any of this resonates with you — whether you’re building healthcare systems, exploring Elixir and Erlang, designing for high availability, or simply curious about a different way of thinking about software — I’d love to hear from you.

After ten years in the dark, it feels good to be back.