That changed when computing hardware began its exponential climb. Computers became faster, cheaper, smaller, everywhere. As hardware accelerated, demands on software rose just as quickly, and this pressure exploded with the arrival of the internet. Today, software is everywhere.

It’s no surprise that by 2025, software has become extremely complex. Yet beneath the layers, every piece of software, from a computer virus to an AI model to a banking backend, is, at its core, a piece of business or domain logic wrapped in a technical shell that allows it to run on hardware.

That shell is rarely simple. It includes SDKs, frameworks, plugins, runtimes, orchestrators, containers, images, infrastructure, and often multiple layers on top of layers. No matter how virtualized or abstracted the hardware becomes, today’s software remains deeply aware of its older sibling. This is why modern applications still deal with databases, message queues, cloud services, endpoints, protocols, and every other technical surface of a computer.

And dealing with those surfaces consumes nearly all developer time. Developers claim to spend 85% of their time on technicalities. I suspect the real number is even higher if you count architecture design, wiring tests, debugging frameworks, and all the accidental complexity needed just to get the “real” logic into a running state.

But the ideal form of software, the one we keep promising ourselves, is a pure expression of business logic and intent. A form where logic stands on its own, completely detached from the machinery that executes it. A form where developers spend their time on the parts that are actually unique and valuable instead of on plumbing. A form that cannot be minimized or abstracted any further, because you would be removing actual functionality.

If we take that ideal seriously, we must confront a simple realization:

The logic of an application and the runtime that executes it should be separate things.

Not metaphorically separate. Literally separate. Logic in software should be as free from technical concerns as a mathematical function. And it should be expressed in a language that captures intent cleanly and directly.

To support this, a new kind of runtime must appear, a logic runtime, one that takes care of every technical concern in a consistent, invisible way. It should give the logic everything it needs, and never get in the way. In other words a world where developers no longer think about infrastructure. Infrastructure thinks about developers’ logic.

If this is the direction software should go, then the first step is to define how we want to express business intent. Only then should we concern ourselves with how to execute it.

Next steps

In the next posts, I’ll explore what this actually looks like in code. Not as abstract ideas, but through real examples of business intent expressed cleanly and directly without the usual technical noise. I’ll show how any domain, from finance to logistics to home automation, can be reduced to logic that reads almost like prose.

Once we have a feel for the shape of this logic-only code, we’ll turn to the other half of the story: the logic runtime. This is the engine that makes the separation possible. I’ll walk through what such a runtime must provide: the functional guarantees, the non-functional properties, and the practical realities like reliability, fault-tolerance, and observability.

And then we’ll look at the numbers. Performance, scalability, latency, throughput, resilience, and security, not as theoretical claims, but as concrete evidence that this new approach isn’t just elegant, but genuinely more powerful.

My hope is that these posts open up a new way of thinking about software: one where developers can focus entirely on logic and intent, while the runtime shoulders everything else. It’s an exciting shift, and I’m looking forward to sharing it with you.

We got hit by reality. To get anywhere, we first had to set up all the generic stuff: authentication, persistence, scaling, monitoring, DevOps. None of it was our actual product, yet it consumed most of our time. What we thought would take months took years. And even once we launched, we were constantly buried under technicalities. Instead of a fresh start, our launch felt like inheriting a legacy system on day one. Progress was slow. It was never the rocket ship we imagined.

Later, I joined bigger and even huge companies. To my amazement, they were dealing with the exact same problems, just with more people and bigger budgets. Looking back, it was clear: developers weren’t the bottleneck, and neither was management. The real problem was the tech stack itself, fighting us every step of the way.

This used to be true for launching simple websites or webshops too. Today, companies like Squarespace, Wix or even a vibe coding tool like Lovable, have vastly reduced that effort so you can be up and running in a day. They stopped website developers from needing to reinvent the wheel. I wanted the same but for software that is a lot more demanding.

At some point, I couldn’t take it anymore. I needed to start from zero. Instead of asking “what’s possible with today’s tech?”, I asked: “what do we actually want as developers?” I wanted tools that let me ship product, not reinvent the tech stack. I checked if what I wanted already existed but couldn’t find anything. Not a product, not even a combination of products.

So, still naive, I started building it myself. And step by step, others joined me along the way (thankfully! 😅). So began a years-long journey of forcing the tech stack to serve us, not the other way around. Sometimes it took painfully long to find the right solution, but we didn’t stop until it worked the way it should.

Out of that work came fluxzero.io, a logic runtime and cloud built to let developers focus on their business logic instead of everything else.

Fluxzero was our refusal to accept the status quo. We didn’t just want functional improvements, like cleaner code, an integrated stack that works out of the box, and effortless communication between applications. We wanted technical excellence too: performance that beats any platform (looking at you Kafka), scalability without headaches, security in the core design.

Why? Because we never want “the tech” to get in the way of shipping, whether you’re launching a startup, serving millions of users or running in a security-critical environment.

Fluxzero wasn’t built to be a workaround. We didn’t want another painkiller, we wanted a cure.

In November 2025, we finally brought Fluxzero to the public. But this platform has been in development for many years, quietly powering mission-critical enterprise systems at crazy scale. For example, Fluxzero runs the core of Dutch logistics at www.portbase.com, handling traffic in the hundreds of gigabytes per minute.

So Fluxzero became the foundation I always wished existed. We built it for every backend developer and for (almost) any application out there.

We’ve been building towards this for a while, and we think you’ll love using it as much as we loved creating it. So start kicking it around and let us know what you think!

– Rene