Early work, kept on the site deliberately

Why these are still here

A beauty salon. A coffee training business. A small technology retailer. A community organisation. Sites for people whose entire online presence this was, built between 2019 and 2023.

None of them are technically impressive and none of them need to be. They are here because a hiring manager reading a portfolio is really asking one question: is this person’s judgement improving, and how fast.

A single large platform cannot answer that. It could have been inherited, or been the one lucky assignment. A line from a booking page to a platform at national scale, with the reasoning visible at each step, is much harder to fake and considerably more informative.

What small business work actually teaches

Three things I would not have learned anywhere else, and all three still shape how I work.

The client is the maintainer. There is no team to keep the site current. If updating it is awkward, it goes stale, and a stale site does active harm. This is where the two minute rule came from that I still apply to every client project: if a routine update cannot be done on a phone in under two minutes, the project has not succeeded, however good it looks at launch.

Nobody cares about the stack. These clients wanted bookings, enquiries, and to be findable. Choosing something interesting to build with, at the expense of any of those, is self indulgence charged to somebody else. It is a useful discipline to learn early, and plenty of engineers never do.

Being found is most of the value. For a small business, a site nobody finds is a brochure nobody reads. That is where I learned technical search work properly, out of necessity, and it is why I can now spot a duplicate canonical from a symptom.

What I got wrong, repeatedly

I over built. Every one of these projects had a feature I was pleased with and the client never used. An animated element, an admin view with more capability than they needed, a filter over a set small enough to read at a glance.

The pattern behind all of it was the same: I built the interesting problem rather than the important one. That is the single most common failure of a developer working without product pressure, and recognising the pull is most of the defence against it.

I also assumed too much. Early on I asked what people wanted and built exactly that, without watching how they actually worked. People describe their problems in the vocabulary of the solution they already imagine. Watching an hour of real use is worth more than any interview, and I learned that far later than I should have.

What carried forward

Handover as a design requirement rather than a document. Content that is server rendered because being found is not optional. The habit of writing down why something was done, which started as notes for clients who would ask me the same question in six months.

The scale changed. The questions did not.