Accidentally in Code

If you’re reading this on cate.blog, things look different. I’m pleased with how it came out. Getting there was more difficult than I expected.

I came into this confident. I used to work on WordPress (admittedly, the mobile apps – but I did the support rotations and lived in P2 like everyone else). I have been running my own site for years. This was not my first visual update, it was just the biggest. I thought my expertise + Claude design would be a winning combination.

It was not.

I knew what I wanted: a stronger brand, something more visually distinctive, an information architecture that put DRI front and centre, more of a “website” than “just a blog”

What went well

The design. Yes, it has the italicised titles characteristic of Claude design. But overall the look is a nice balance of pops of color but not in the way of reading. The goals have been met, and I’m really pleased with how it looks.

I love Claude Design, high on updating DRI Your Career I was looking for other things that could be prettier. I also used Claude Chrome to validate: visual detail at the level of font sizing and spacing is not a strength of mine, so it was incredibly useful to go through multiple rounds of checks and the entire site to ensure that everything had been applied just so.

What went poorly

TL;DR: WordPress.

I started using Claude Code as an issues manager and lookup engine, but after a day of this, frustrated by how much slower the progress was than I’d expected, I connected Claude Code directly. This was a huge accelerator, although I had to pay attention that it built block components rather than making everything custom – I do want to be able to edit it, after all. But even with that working, CSS edits still had to be copied and pasted.

I made a staging site, which I have never bothered to do before – probably something that had kept the scope of my previous redesigns small, ensuring that I could keep a working and visually acceptable website as I went.

I’d decided against a child theme, on the reasoning that child themes don’t receive updates and those are important. However because all the customisation lives as configuration in the database instead of in theme files, appearance and content are in the same place. Deploying staging to production took two hours, took my site down while it ran, and broke Jetpack on the way. I knew this going in (well not Jetpack breaking, that I had checked a box to prevent), when I set up the staging site, and decided to go with it. But it is still horrifying.

I moved from Twenty Twenty-Three to Twenty Twenty-Five, which is extremely minimal; very little is defined until you define it. As the definitions live in two places, Global Styles and a separate CSS block, any given margin might be set in either. Reconciling that was fiddly and irritating.

I always heard web developers be dismissive of WordPress, and I didn’t fully get it, because what I have always loved about it was that it was easy to write in, and that was my goal of having a website. But having dealt with this I get it. The tooling is just so frustrating.

Now that I have more of a brand, I decided to update What Raccoon to match – it’s more prominent on the site and felt jarring to switch, so wanted them aligned.

Yes, it’s a much smaller site. But it took 10 minutes and had one minor bug: keyboard detection in Chrome. Done.

cate.blog? Four days. Yes doing other things, but I maxed out my Pro plan twice in one day working on it. The last time I did that, I was making a 50 page slide deck (for the first time, inefficiently). My website is not that big. The difference in effort was wildly out of proportion to the difference in complexity. What’s interesting to me is the gap between where AI accelerates and where it doesn’t. WordPress – the speed increase did not match the increase in my ambition. But for a regular website? The speed increase is driving my ambition.

What I’d do differently

I did write GitHub issues, but they were the spec I handed Claude Code to work through, not a tracker I was keeping for myself. As things got more complex, I was missing one source of truth for me, across the three Claudes and all the manual steps in between, that stayed current as the work moved.

So, next time:

• Treat it like a project for real: not just a spec to kick things off, but a source of truth I keep current as I go, so the plan and the actual state don’t drift apart.
• Content backed up to GitHub so there’s real version control on it.
• Still build the staging site to test against, but deploy by connecting Claude to the live site and having it move the changes across, rather than deal with deploying and all the problems that entailed.

• A better way to keep Claude Design, Claude Code, and Chrome-for-validation in sync with each other. A validation checklist living in GitHub would go most of the way.

I’m keeping the new look, and I still have a deep love of Claude design. But my WordPress ambitions? Those will be tempered for a while.