Everything is a translation problem

The first program I wrote that meant anything didn't do anything useful. It took a number, decided whether it was prime, and printed the answer — the kind of exercise a textbook calls trivial. What stayed with me wasn't the code. It was the moment it ran: the realisation that I had described a small piece of the world precisely enough for a machine to act on it without me standing over its shoulder.

I was a teenager, and I didn't have the vocabulary for what I'd felt. I have it now. It was the pleasure of exactness — of saying something so clearly that it leaves no room for misunderstanding. Growing up between three languages had already made me sensitive to the opposite: how the same sentence shifts meaning depending on who's listening, how much is carried in the space around the words. Software was the first place I found where that ambiguity could be pinned down and made to hold still.

I studied formally, but the education that shaped how I actually think happened somewhere off the syllabus — documentation read at midnight, things broken and rebuilt until they made sense, answers from strangers on forums who owed me nothing. The curriculum gave me range and the nerve to be the least experienced person in a room and still say something worth saying. The forums gave me everything else.

Nobody taught me the part that mattered. They just left the door open and let me find it.

The early years were deliberately wide. JavaScript one day, SQL the next, deployment scripts on a Sunday. I distrusted specialising before I understood how the pieces fit, because you can't redesign a system you've only ever seen one face of. Breadth wasn't indecision. It was reconnaissance.

Aller Media gave me my first encounter with real scale — one of Scandinavia's largest media groups, its titles read by millions, all of it resting on a content platform that had aged past its limits. I spent two years there as a senior backend developer, leading the migration off a constrained Umbraco CMS onto Optimizely across several brands. It taught me to treat old systems with respect rather than contempt.

A legacy codebase isn't a monument to incompetence. It's a record of decisions that each made sense to someone, under pressure, with the information they had. Read it that way and it starts telling you things.

Commerce found me before I went looking. One project, then another, then the unmistakable sense that this was a domain that rewards depth in a way generalism never could. How a payment flow leans on inventory. How personalisation reaches all the way down into fulfilment. The quiet war between editorial control and conversion. These problems don't resolve cleanly, which is exactly what makes them worth the years.

I've built stores for creators selling directly to their audiences for the first time on Shopify, and for B2B distributors carrying thousands of SKUs, tiered pricing, and multi-step approvals on Commercetools. The platforms keep changing. The underlying question never does: how do you make the experience feel effortless for the person on the other side of the screen?

The answer, almost always, is somewhere the customer will never see.

The work that rearranged how I think is Clever — Denmark's largest EV charging network, and the place I still go to work. When I arrived, the platform had outgrown the architecture holding it up. Several teams were wiring themselves directly into the same third-party systems. Infrastructure was straining. A single change in one corner would quietly break three things somewhere else, often without anyone noticing until a customer did.

Over the better part of a year, as the architect and a working pair of hands, I rebuilt the integration layer from the foundation up — replacing brittle direct dependencies with a proxy-service architecture on Azure Container Apps, moving the communication between services onto reliable, event-driven messaging through Service Bus, and taking the platform from one active sales channel to seven. The system could be watched at last; failures were traceable, deploys safe enough to be boring. That rebuild was the start of the job, not the whole of it — I stayed for what came next, and I'm still there.

.NET and C# became my primary language by conviction, not convenience. When the thing you're building moves money, reconciles customer records across half a dozen CRMs, or holds thousands of connections open at once, you want a runtime whose edges you know in the dark — its type system, its async model, the places it will surprise you. I know those edges.

Backend work, done properly, is a discipline of guarantees. That the data stays consistent. That the message arrives. That a failure can be recovered from instead of quietly swallowed. It's invisible when it's right, which is both the cost and the whole point. Nobody thanks the plumbing until the day it doesn't hold.

My title now is architect, and I earn it at Clever — the EV charging network from a few chapters back. Rebuilding their integration layer turned into staying for what came after: I'm still there, shaping where the platform goes next. I'm most useful inside a team with the full picture, in the same conversations and under the same constraints — not advising it from the outside.

These days I design systems more than I write them. The centre of the work has moved — from the keyboard to the whiteboard, from implementing a service to deciding which services should exist, where the boundaries fall, and which choices will be expensive to walk back. The hardest hours now go into the diagram, not the diff.

An architecture I can't implement myself is just an opinion. I still read the code closely, and write it when a design needs proving.

That's the line I try to hold: enough distance to see the whole system, enough proximity to stay honest about what it costs to build. The day job is where I design at that scale. The rest happens on the side — a small e-commerce practice for a handful of clients, and a product of my own that I'm only getting started on.

My curiosity doesn't clock out when the invoices stop. I read systems papers for the same reason other people read crime novels — for the satisfaction of a problem set up properly and then taken apart. I keep small experiments running on the side, mostly to feel how a new tool behaves before I'd trust it near anything that matters. And I've been watching, closely, how AI tooling is quietly rewriting the texture of the craft itself.

Away from the screen, I follow football with more conviction than is strictly reasonable, and I read widely — history, biography, the occasional novel that has nothing to teach me and is better for it. My daughters are at the age where every answer earns three more questions, which turns out to be excellent training for architecture: stay patient, stay curious, keep moving while the picture is still incomplete.

The territory I find most interesting sits where AI meets the unglamorous systems that actually run commerce and integration — not the broad cultural noise around it, but the specific engineering question of how intelligent processing changes what we build and how we reason about correctness when part of the system can no longer be fully predicted. That's a question worth taking seriously for the next decade, and I intend to.

VelaCommerce will take most of my attention in the years ahead. Building a product company is a genuinely different animal from running a services one — different incentives, different feedback, different ways to fail. I'm early in understanding those differences, and I've learned to recognise that feeling. It's the same one I had as a teenager, watching a small program run for the first time.

Every chapter so far has been the previous one's harder version. I don't expect the next to break the pattern.