A website without WordPress

For ten years, WordPress stood here. It worked until it didn’t — and lately it mostly didn’t; before I got around to the rewrite, the home page was coming back as HTTP 500. Which is actually a good reason for a rebuild.

Why rewrite it

I make my living developing software. Having my personal site on a WordPress I log into three times a year just to click through the updates struck me as a small professional irony. I wanted three things:

1. The site should reflect what I do. When someone comes over from LinkedIn, they should see something I built myself, not a template that a thousand other people have on their sites.
2. It should be maintained by writing, not clicking. Content as plain text files next to the code, not rows in a database that I need a password and an admin panel to get at.
3. I should be able to experiment with it. You can bend WordPress, but it hurts — and pain is the most reliable way to put someone off trying things.

How it’s built

Nothing exotic, and that’s deliberate. I write it in the same technology I use for clients — .NET. It sounds obvious, but it has a practical consequence: whatever I try out here, I can offer to clients right away, and the other way around.

Each page is assembled in full on the server and only then sent to the browser, so it appears practically instantly — nothing loading in afterwards, no waiting for JavaScript to get going. The content — text, captions, whole articles — sits in plain text files next to the code, not in a database. I change a file, save it, and it’s on the site. Nothing extra has to be installed, and nobody has to keep watch in case a new version with a security hole has come out.

And the whole thing runs in Docker on my own server — essentially the same setup I described in an article back in 2016. What’s changed is what runs inside the container, not how it’s operated.

The more interesting part

I don’t maintain the site by hand. The repository holds a set of instructions for AI agents — who plans, who designs the look, who writes the code, who checks it all. When I want to add an article or rework a section, I describe what I want and the roles pass it along between themselves: one breaks the brief down into steps, the second proposes how it should look, the third writes it, the fourth critiques it.

It sounds like overkill for a personal website. It probably is overkill. But it’s also the best training ground I have — low risk, real production use, and when something breaks, the only person it annoys is me.

What I get out of it

A site that doesn’t break on its own, because there’s almost nothing in it to break. Content I can edit in five minutes instead of hunting for the admin password. And a live system where I try out how to work with agents before I roll out the same thing for a client.

The repository is private for now. If you’re curious how any of this is done on the inside, drop me a line — I’ll gladly show you.