You don't need WordPress any more

I ran WordPress for years — my own sites and clients'. Before that it was Blogger, and before that Subtext, which tells you how long I've been doing this. WordPress was the platform I stayed on longest, and for a good while it deserved that. It did everything, plugins filled every gap, and everyone already knew how to use it.

This is about what changed — not as a theory about where the web is going, but as what actually happened to my sites.

The speed problem ate real infrastructure

The WordPress sites I ran were never fast enough, and the fix was always more machine. I've hosted them on cPanel, on VMs, and eventually on a dedicated server. I've run HHVM, and stacked WP Super Cache on top, all to keep pages responsive. Every setup bought a little time. Then the creep started again, and the next fix was more infrastructure again.

At some point you have to notice what you're doing: renting bigger machines so your publishing software can re-render the same page, thousands of times, for every visitor. The words aren't changing between requests. The work is being repeated anyway, and you're paying for it every month.

I got hacked because I dared to be asleep

One of my sites got hacked because I dared to be asleep when a patch came out. That's the whole story, and it's exactly as stupid as it sounds: the patch landed, the exploits followed, and I was unconscious for the window in between.

What stuck with me wasn't the cleanup. It was the dependency the whole model rests on — my being awake. A site that needs a human to respond within hours of a patch release doesn't have a security posture. It has a hostage situation. And patches weren't rare: between core, the theme, and the plugins every site accumulates, there was always something, and every one of them was another small window like that one.

I don't need anyone's vulnerability statistics. I lived one.

My content wasn't mine, in practice

The other rot was quieter. Years of posts, and the formatting had accreted inside them — HTML mixed in with the content, styles inline, every article a little different depending on which editor and which era produced it. The design of the site was inconsistent because the design was inside the content, where I couldn't restyle it.

And I couldn't manipulate any of it at scale. No find-and-replace across years of posts. No way to answer a simple question about what I'd written without clicking through an admin screen one article at a time. The content sat in a database that only WordPress speaks, and I had access to exactly what WordPress decided to show me.

Then I moved, and the problems just stopped

I moved to Jekyll, and later to Nuxt Content, which is what this site runs on. The model is different in a way that's hard to overstate: the content is Markdown files in a repository. A generator reads them and writes out finished HTML. A CDN serves the files. When a visitor asks for a page, nothing executes. There is nothing to execute.

And everything that had been hurting resolved by itself, with no cleverness at all.

The patch race ended, because there's no server-side application to patch, no /wp-admin waiting to be found, and no database to inject into. I still maintain things — the generator, its dependencies — but I do that on my own schedule. Nobody can start that job for me, and being asleep is no longer a vulnerability.

Speed stopped being a project. A page's response time is a file lookup near the visitor, so there's nothing to tune and nothing for an update to regress. No HHVM. No cache plugin. No dedicated server for a site that mostly just sits there.

And the content problems dissolved the moment the content was files. Find-and-replace is a command. A question about years of posts is a search. The design of the site and the words in it are separate things again, so each can change without the other. Every change has a diff, every version is recoverable, and the next time I change platforms the migration is a copy — because Markdown is the one format every tool in this space reads.

The one thing I actually missed

Editing, and I'll be honest about it because pretending otherwise helps nobody. It was never a hardship — I live in a terminal, and Markdown in a repository is where my content wants to be. But I never loved it either, and it took me a while to work out why. A blank WordPress page felt like somewhere to write. A new Markdown file was another tab in the editor I'd been debugging in all day, same font, same sidebar, same keystrokes as the work. Something in that flattens the writing. Less flow, and less inclination to be bold.

Images were worse, and far less subtle. Cyberduck open in a second window to push a file up by hand. Then, weeks later, trawling back through old posts to find the one that used the photo I wanted again, so I could copy the URL out of it.

That was the experience for someone who likes Git, Markdown and the command line.

I don't only build sites for myself. Kerry's agency runs a much bigger site with several authors, and what it needs is a stack where none of them ever has to see Markdown, let alone Git. So we went looking for a Git-compatible headless CMS, and then kept looking. Forestry, which we liked, until it was retired in favour of Tina, which never fitted. Then CloudCannon, which we grudgingly got by on — until we didn't.

Every one of those moves cost setup time that came out of the same budget as the writing, and asked everyone to learn a tool that would be replaced again soon enough. Each of them charged by the seat, too, so the obvious economy was always to have fewer people with accounts.

Which is how you end up watching the only number that mattered go quietly the wrong way: how many people could, and would, put words on our sites. The tooling was deciding who got to speak, and it kept deciding fewer.

So we built Intracia: a structured editing workspace over the Markdown already in the repository. Real fields instead of raw frontmatter, drafts and previews, and the media library sitting where you're writing rather than in a separate application. The files stay exactly where the generator expects them. Nothing about the site itself changes.

That was the last thing I missed about WordPress, and the only thing.

The honest boundary

None of this is universal. If you render something different for every visitor — a shop, an account, anything personal — you need something that runs per request, and WordPress still does that job. I won't talk anyone out of a tool they genuinely need.

But most of the sites I've built over the years aren't that. They're marketing sites, blogs, documentation — the same words served to everyone. For those, I spent years paying for flexibility I never used, and the bills were the servers, the patches, the hack, and the content I couldn't touch.

If you're in the middle of that calculation and want a straight answer on whether the move is worth it, tell me what you're running.