Some things I build because I need them. Some things I build because I’m trying to understand something. And some things I build because I’ve built them before — and I want to see how I’d do it now.

One of the more consistent examples of that is a small tribute page to the Range Rover L322.

Not because the world needed another page about it, and not even really because I owned one for a while — although I did, and it remains my favourite shape of Range Rover. Boxy, but still modern. Somehow it’s aged better than it has any right to.

The page itself is trivial. A few images, some layout, a bit of structure. Nothing complicated. But I’ve rebuilt it multiple times over the years. First as plain HTML and CSS, mostly to get a feel for how things like HTML5 and CSS3 had evolved while I wasn’t paying close attention. Build it, look at it, delete it.

Then again in PHP — deliberately without a framework — which felt harder than it should have, mostly because I’d spent so long not working that way. Then in Laravel. Then again in a newer version of Laravel.

Each time, the same basic idea. The same structure. Just using whatever tools or patterns I was interested in at the time. New components, different approaches, small improvements. It’s not a project in the traditional sense. It’s more like a fixed point I return to — a way of measuring how my thinking has changed.

Other explorations are much more specific.

At one point, we realised my eldest son was struggling with number bonds at school. Not because he didn’t understand the maths — he did — but because the tests were timed. Ten questions, one minute. Enough pressure that hesitation became the real problem.

So I built a small web app.

Something I could open on my phone, configure quickly, and generate a short test. Addition up to a certain number, ten questions, adjustable time limit.At first, the timing didn’t matter. Just getting comfortable with the questions. Then gradually reducing the time available, helping him build confidence under pressure. It worked.

He went from repeating the same level for weeks to scoring consistently high enough to move up every week or two. Not because the maths changed, but because his approach did. More recently, I adapted it again. The questions became uneven in difficulty, so the focus shifted to strategy — recognising that getting 9 out of 10 quickly is better than getting stuck chasing a perfect score. Same idea. Slightly different problem. Small adjustment.

Then there are the things built out of frustration.

In project management, an uncomfortable amount of important information lives in spreadsheets.

They’re good at holding data.
They’re not good at communicating it.

So rather than forcing people to interpret raw data — or constantly asking for updates — I started building simple dashboards. HTML, CSS, sometimes a bit of JavaScript. Something that could take the underlying spreadsheet data and present it clearly:

baseline vs actual
budget
RAG status
key updates
blockers
useful links.

Nothing especially sophisticated, but enough to turn static data into something readable. If I could find someone willing to host it — on Apache, IIS, wherever — it became a shared view into the state of a project. No gatekeeping, no bottleneck. It didn’t work everywhere. Some organisations wouldn’t allow it at all. But when it did work, it made things noticeably smoother.

Looking across these, there isn’t a single unifying “project”. There’s no grand outcome, no single thing to point at and say that was the goal. But there is a pattern.

Revisiting the same idea to see what’s changed.
Building small tools to solve immediate problems.
Taking something static and trying to make it more useful.

None of them are particularly large. But they compound. And more often than not, they start the same way: “I wonder if I could just build something that does this.”

L322 Tribute screenshot