Background: How I Got Here

There are careers that follow a line.
Mine behaved more like a network.

It didn’t start with systems thinking. It started with something smaller: making things work.

My first real encounter with complexity wasn’t in code, but in a furniture company. A few showrooms, a factory, trucks moving products from one place to another. At first, everything seemed manageable. Orders arrived slowly. Lead times were long, but accepted.

Then the pace changed.

Orders grew from a few per week to dozens per day. Lead times shrank. Pressure accumulated in places that had previously gone unnoticed. What worked before started to fracture.

Not in one place. Everywhere.

We started building tools. A webshop. Then another. Then internal systems to replace spreadsheets that had quietly become the backbone of the business. Each tool solved something, but also revealed something else.

Data existed, but it didn’t flow.
Decisions were made, but not propagated.
Processes worked, but only locally.

At some point, it became obvious:

We weren’t building applications anymore.
We were mapping a system.

The product catalog forced this realization. Hundreds of furniture types. Modular shapes. Thousands of materials. Every part customizable. The number of possible combinations grew beyond anything that could be reasoned about directly.

It stopped behaving like data.
It started behaving like space.

A space so large that brute force thinking collapses.

What we built was not a configurator. It was a constraint-aware navigation system. Something that didn’t try to enumerate possibilities, but guided you through them without letting the structure fall apart.

Once the data became structured enough, it started to move.

From design tools, through production planning, into material requirements, procurement, and stock management. Each step transformed the data. Reduced it. Focused it.

What began as input became flow.

Inside the factory, this flow had to become physical. Materials needed to exist in the right place at the right time. Components had to be tracked as they moved between workstations. Temporary storage became part of the system, a constantly shifting map of where things are and where they need to be.

Then logistics extended the system beyond the factory walls.

What once existed as a combinatorial idea had to arrive as a real object in someone’s home.

The system had to survive contact with reality.

By then, the boundaries between domains had dissolved. Sales, manufacturing, logistics, and marketing were no longer separate concerns. They were different perspectives on the same structure.

That’s where the shift happened.

Not from developer to something else, but from thinking in features to thinking in relationships. Not in tools, but in flows. Not in isolated problems, but in systems where every decision has a downstream consequence.

Looking back, most of this doesn’t appear on a CV.

What it won’t show is everything around it.

Building electronics. Working in commerce. Handling deliveries. Prototyping hardware. Running small experiments that had no immediate business value, but quietly built intuition about how things behave outside the screen.

A temperature sensor for commercial fridges.
An RFID access system.
A weather station.
A barely-working ESP camera stream running at seven frames per second.

Individually, none of these matter much.

Together, they form a pattern.

Some systems are designed to scale.
Others just need to endure.

I’m still not sure where this path leads.

But I know what kind of problems pull me in without effort. The ones that are not fully defined yet. The ones that connect multiple domains. The ones where solving them means understanding how things interact, not just how they work in isolation.

That’s where I feel useful.

And that’s where I keep going.