Apparently, I Still Build Things

What I Built Next is a series I started on LinkedIn about the things I’ve been building outside my day-to-day work — personal projects, experiments, old hardware given new jobs, and ideas that got slightly out of hand.

The shorter versions of these stories are published as posts on my LinkedIn profile. Here on my website, I’m giving them a little more room: more of the story, more technical detail, more of what went wrong, and some of the decisions and lessons that didn’t fit comfortably into a LinkedIn post.

If you’d rather follow the series in smaller doses, you can follow me on LinkedIn. If you’re here because one of those posts sent you down the rabbit hole, welcome — this is the longer version.

For most of my career, building things was my job. Websites. Software. Interfaces. Internal tools. Research projects. Design systems. Things for clients. Things for companies. Things that had requirements, deadlines, tickets, meetings and, inevitably, meetings about the meetings. Then something changed.

I stopped building things because somebody asked me to. And started building things because I was curious again. That distinction turned out to matter more than I expected.

Going back to where I started

I’ve been making things with computers for most of my life. My first computer was a Sakhr MSX in 1989. I discovered BASIC and the wonderful idea that you could type instructions into a machine and make it do something that hadn’t existed a few minutes earlier.

That feeling never really went away. The tools just became more complicated. BASIC became HTML and CSS, then JavaScript. Then, as any developer, databases, APIs, frameworks, cloud infrastructure, containers and all the other layers we’ve managed to place between an idea and the computer actually doing something.

Along the way, building things became a profession. I worked in graphic design, web design, software development, research and engineering. I built websites and applications for businesses. I worked on research platforms. Eventually, I worked on large enterprise systems with hundreds of engineers involved.

The projects became bigger. The technology became more sophisticated. But something else happened too.

The distance between having an idea and making the idea exist became larger.

Professional software is supposed to work

This is, obviously, a good thing. When people depend on software, experimentation has consequences. There are requirements. Architecture discussions. Code reviews. Accessibility requirements. Security reviews. Testing. Deployment pipelines. Documentation. Release schedules. Stakeholders. And Jira. Always Jira.

You can’t generally walk into work on Monday morning and announce: “I found something interesting on GitHub at 2 a.m., so I’ve replaced half the infrastructure.”

Apparently this is considered poor change management. But that slightly irresponsible curiosity is also how many of us learned technology in the first place. We took things apart. We installed software we didn’t understand. We broke operating systems. We opened devices that probably weren’t designed to be opened. And occasionally we fixed them again. I realised I missed that.

So I started building things for no particularly good reason

Not products. Not startups. Not things accompanied by a pitch deck explaining the total addressable market. Just things I wanted to exist. Sometimes because I had a problem. Sometimes because I wanted to learn a technology. Sometimes because an existing solution annoyed me. And sometimes for the worst possible reason: because I wondered whether I could.

That last category is dangerous. It is responsible for an unreasonable percentage of the projects in my house.

The joy of unnecessary engineering

There is something wonderfully liberating about building something that doesn’t need to become a product. It doesn’t need investors. It doesn’t need thousands of users. It doesn’t even need to make sense to anybody except me. If I want to spend an evening creating a service that saves me thirty seconds a week, the business case is irrelevant. If I want to take an old computer and turn it into a server instead of buying a new device, nobody is calculating my engineering cost against the price of the hardware. If I want to connect two systems simply because I want to understand how they communicate, that’s enough. Of course, there’s an irony here. These supposedly pointless projects have taught me an enormous amount.

Building became learning again

When you’re working inside a large technology organisation, your world can become surprisingly specialised. You may be working on an incredibly complicated system while interacting with only a small part of it. Personal projects remove those boundaries. Suddenly you’re responsible for everything. The interface. The backend. The database. The network. The deployment. The security. The documentation. And the confused user wondering why the application doesn’t work. Unfortunately, the confused user is also you. That makes personal projects excellent teachers. They expose the gaps between the things you know professionally. And because nobody is waiting for a sprint review, you can follow those gaps wherever they lead. One evening of curiosity can turn into three weeks of learning about something you had absolutely no intention of studying. I’ve discovered that I rather enjoy that.

Then teaching changed how I built things

Teaching software development added another dimension. When you have to explain something, “I know how to do this” isn’t enough. You need to understand why it works. You need to anticipate where someone will get confused. You need to break complicated systems into understandable pieces without pretending they’re simpler than they really are. That changed how I approached my own projects. I started documenting more. I started questioning decisions I’d previously made automatically. Why this framework? Why this architecture? Why am I adding another dependency? Could I explain this to someone who hasn’t spent years staring at code? Sometimes the answer was uncomfortable. “Because everyone else does it” isn’t a particularly satisfying technical explanation. Neither is: “I copied it from Stack Overflow eight years ago and it has worked ever since.”

Teaching made me curious about technology again in a different way.

Old hardware is particularly dangerous

I also have a weakness for old electronics. I dislike throwing away technology that still has some useful life in it. A computer doesn’t become useless simply because it can no longer run the latest fashionable workload. Sometimes it just needs a different job. An old PC can become a server. A Raspberry Pi can become part of a smart home. A forgotten drive can become storage. A strange little device from a thrift shop can become… Well. That one deserves its own story. Because one day I walked into a thrift shop and found a small ARM-based computer called a Firefly Station P1 Pro. It was new in the box. It was cheap. I had never seen one before. I absolutely did not need it. So naturally, I bought it. I took it home, looked at it and asked the question that has caused me an extraordinary amount of trouble over the years: “I wonder what I can do with this?” That question became a homelab. But that’s Part 2.

What I Built Next

That’s what this series is about. Not tutorials, exactly. Not a portfolio either. It’s the story of the things I’ve been building, fixing, breaking, redesigning and occasionally finishing. Some are software projects. Some involve hardware. Some solve genuine problems. Others exist largely because my brain refused to leave an idea alone. I’ll explain what I built, but also why I built it, what went wrong and what I learned along the way. Because after years of building technology professionally, I’ve rediscovered something I knew when I first sat in front of a computer as a child:

The best way for me to understand something is still to build it.

And occasionally break it. Then build it again.