When I first built this site, I invested a lot of time in getting it up and running. I figured that would be more or less it for a while, since that’s how we used to build sites: plan, design, build, launch, fix some bugs, live with it.
But after launching this site, I noticed things that bothered me, or things I preferred would work differently, or types of content I wanted to add, and because I have Claude by my side, I could just go ahead and make the changes. Nothing was off limits for me in terms of knowledge, capabilities or time (although to be honest, working on the site with Claude still can take a lot of time that I woudn’t otherwise be investing in it).
So ever since this site launched, I’ve been iterating on it pretty regularly, always improving, always aiming for it to be better and better – because I can! It’s really fun 🙂
Whenever I talk excitedly to people about my site, they’re like “but what’s interesting about it?” and it’s hard to explain. What’s interesting about it is that it has a pretty smart content infrastructure, good performance, accessibility, user experience, and perfectly suits my own needs. But when people judge a site, they do so by just looking at it and then they go, meh, it looks like any other site.
So I started maintaining a local changelog to document all the tweaks and changes, why they happened, and how.
And then I thought – a site should be treated like a product. It is meant to make the user happy and the end user happy, and it should be constantly iterated on, and it also deserves a shared changelog.
Planning my changelog
I wanted my changelog to feel like the rest of the site: retro terminal aesthetic, same monospace type, the same “this is a living thing” energy. Claude and I decided on a feed that is reminiscent of a git log: version badges, release dates, a stats strip that counts the entries and shows how long this has been going on, all computed at page load rather than hardcoded anywhere.
The first version felt like a wall of text so we added a feature that collapses the entries by default, showing just the version, date, and title, and they can be expanded on click.
Deciding on the type of content
I wasn’t sure how technical to get in the entries. I’m writing for two audiences here: there’s the people who would care about a changelog on a personal site, like developers and other people building with AI, who may be interested in the technical details. But I also wanted it to be useful and explain why I made changes, and what the thinking was behind them, for the general WordPress and web audience.
So I decided that the entries would share both types of content, including describing things that didn’t work, why, and how they were fixed.
I did make it clear to Claude that the public changelog shouldn’t share anything that could pose a security risk. So the changelog just shares what changed and why, but not the infrastructure underneath it.
Backfilling the history
I didn’t want the changelog to start empty on day one. Instead of writing sixteen entries from scratch, Claude converted my local changelog doc into public-facing posts and delivered it as a WordPress import file, which I was able to load in one step (love the WordPress Import function!).
When I uploaded the import doc, every post got today’s publish date, rather than the date when the change happened. We fixed this by creating a dedicated custom date field on each entry, separate from WordPress’s own post date. This pattern is already used on this site for my events and media appearances Custom Post Types. Now the feed sorts and displays by when something actually shipped, not by when I got around to publishing it.
How it stays alive
From now on, every time I finish a session with Claude that ships something worth mentioning, Claude creates a draft entry on the site for me to review and publish. I don’t have to remember to update a changelog separately from doing the actual work since it’s now part of our session wrap up process.
The very first entry on the page is about the day this site started, which is the day I started to learn what it means to build WordPress websites with AI – it’s a never ending process of always iterating to make it better on every level, because I can.
Good times 🎉
