Twenty years of learning where things break.

How I got here

The computers came first. I grew up around them and had my own by the time I was eight, working it out as I went, and by my early teens it was obvious which direction I was heading. Getting paid for it took longer.

The first trade was welding. Two years building ambulances at a vehicle manufacturer: chassis parts, assembly, the sort of work where a bad weld is not a style opinion. It taught me something that stuck. What you make has to hold under load, and it is obvious to everyone when it doesn’t.

Then the career in software arrived, from the bottom up.

Systems and networks first. Four years of Linux and Windows administration, firewalls, and VoIP telephony down at the protocol level: SIP, H.323, Asterisk, plus the client-server architecture around it and the third-line support work where you find out what production is really like at three in the morning.

Then the software running on top. Four years as a lead developer building CMS and e-commerce platforms, custom backends, APIs and real-time systems, running the servers they lived on at the same time. Somewhere in there I needed a message bus that did not exist, so I wrote one: HexxoreCore, distributed, with its own IANA-registered port. That is roughly when building the missing tool stopped feeling like a detour and started feeling like the job.

Then the cloud and the automation that puts the whole lot into production.

What that order is actually worth

What that list is worth is knowing where things go wrong. Rarely the clever bit in the middle. Far more often it’s the deployment, the migration, the integration that fails without saying anything, or the awkward discovery that nobody ever wrote down what the system was supposed to do.

It was always software people leaned on, the sort that quietly runs somebody’s operation in the background, where a bad afternoon for the system is a bad afternoon for everyone using it, and “works on my machine” is not an answer anyone can use.

Learning it in that order means I can take something from an idea to a system that actually runs, without handing it over halfway. Design decisions get made by someone who will also be carrying the pager.

Building the missing tool

There is a pattern to how I work that is worth being explicit about, because it is where most of what I know actually came from.

Day to day the work is connecting business systems that were never designed for each other and automating the manual work between them. The same brittle glue code kept reappearing: a script here, a scheduled job there, nothing that could tell you what it had actually done afterwards. Rather than rebuild that glue for the fifth time, I built the thing that should have existed: real process automation, with a record of every run and a sensible place to put a human decision.

Then AI coding agents got good, and the bottleneck moved. The agents could do the work; what they couldn’t do was any of the things a team does without thinking about it. Keep a shared picture of what’s in flight. Notice when something is stuck. Work out when a human needs to weigh in. I tried the obvious fixes. A screen full of terminals, one agent per tab, scripts to queue up prompts. Every version had the same hole: no shared workspace, so each agent was a solo act, and I was the only thing holding the picture together. That works right up until you look away. So I built that too, because I wanted to keep building with agents rather than in spite of them.

Working that way changed my mind about something else. When the cost of shipping a small, well-scoped service drops far enough, a lot of problems stop needing big software at all. They need something small, deployed properly, that someone can actually run without a platform team.

None of this started as a market opportunity. Each one was a problem I kept paying for. The useful part for a client is that the opinions I bring to your project are ones I’ve had to live with in my own.

How I build

The bias is always solid over clever. These are things other people depend on, which makes solidity the product rather than a tax on it. In practice: tests written before the code, explicit state machines for anything long-lived, and external systems kept behind interfaces so a vendor can be swapped out without a rewrite.

It also means the unglamorous guarantees aren’t up for negotiation: logging, backups, metrics, monitoring, and an audit trail that can answer “what actually happened, and when?” That last one matters more than ever when the thing that acted was an agent rather than a person.

I’m an open source advocate. It’s what I learned on and it’s what I reach for first. That said, not everything I build is self-hostable, and I’d rather say so plainly than imply otherwise. What is consistent is thinking hard about lock-in before taking a dependency, and being honest about the ones we couldn’t easily walk away from.

Working with Hexxore

Hexxore takes on engineering work: building software out of a rough idea, straightening out a platform that has drifted, connecting systems that should have been talking years ago, or automating the manual work in between. Running our own infrastructure means the advice comes from having lived with the consequences rather than from a slide.

If you have something that needs building, I’d like to hear about it.