How I built this website

What it is

The site you are reading. I wrote the specification, Claude Code built it, and I reviewed and revised from there.

Why I built it

I wanted to find out what it is actually like to direct one of these tools on a real piece of work rather than a toy. Something that has to be correct, has to be maintainable, and has to still be mine in six months. A times tables app forgives a lot. A site with my name on it does not.

How I built it

It is a static site, so every page is built in advance, which keeps it fast and cheap to run.

The decision I care most about is that the words are completely separate from the code. Every sentence here, including headings and button labels, lives in a plain text file. I can change any of it, or add a new case study, without touching the build. That was a requirement written into the brief rather than something asked for afterwards, and it is the difference between a site I own and a site I have to ask someone to edit.

The other decision was to specify the things that were not negotiable before any code existed: structure, palette, what the pages had to do, how it should read to a search engine and to an AI assistant summarising it. Anything left unstated got decided for me, reasonably and generically.

What didn’t work

The first design direction was generic and I rejected it. So was the second attempt at the same problem, and the reason both times was that I had described what I wanted in adjectives rather than in decisions.

These tools move the bottleneck towards judgement, not away from it.

I also built a career timeline module, liked it, and cut it. It was accurate and it put far too much on the page. Building the thing was what told me it was wrong, which is an argument for building sooner rather than specifying longer.

What I took from it

The value was almost entirely in the brief, not the build.

The code was the fast part. What took the time was deciding what the site should say, who it was for, what to leave out, and which decisions had to be non-negotiable so they would not quietly get optimised away. Where I was specific I got what I wanted. Where I was vague I got something generic, and the fix was always to go back and decide properly rather than to ask again.

That maps closely onto commercial work. A capable delivery function will build what you specify, at speed, and the constraint sits with whoever has to decide what is worth building.