Why I Built My Own CMS in 2026

There are plenty of good ways to put a blog online. I used none of them and wrote my own. That was not the sensible choice, and I want to be honest about it, costs included, because most “I built my own CMS” posts skip straight to the victory lap. Some of what follows is reasoned. Some of it is just personal taste. I’ll be clear about which is which.

The tools I said no to

“Not invented here” isn’t a reason. Here are the real ones, starting with the one I’m least objective about.

• WordPress is where I have to admit a bias up front: I can’t stand it. It started life as blog software, and honestly it’s still fine at that. But somewhere along the way it became the default answer for every corporate site on the planet, a job it was never designed for and doesn’t do gracefully. Under the surface it’s hauling around close to twenty years of legacy and backwards-compatibility it can never quite put down, and you feel that weight the moment you try to do anything slightly against its grain. Pile on the endless patching and hardening a public WordPress install needs, and on a personal site I’d burn more evenings maintaining it than writing in it. It was a no from me before I even got to the technical objections.
• A static site generator is lovely. Fast, cheap, almost nothing to attack. I nearly went this way. It fell down on the three things I wanted most: a real admin to write in, scheduled publishing, and translations that aren’t an afterthought. You can push flat files into doing all three, but you feel the tool leaning back against you the whole time.
• Something hosted, Ghost or a Notion-backed setup, is the least effort by a wide margin. If all I wanted was to write, I’d have signed up and been done before lunch. But it runs on someone else’s software and someone else’s plan for it, and this is one of the few things I wanted fully mine.

What I was really after

Strip the comparison away and there were a handful of wants underneath. Every decision in the codebase leans on one of them.

Ownership first, in the dullest literal sense. Something bugs me, I open the file, I change it. No waiting on a plugin author. No reshaping the idea to fit a settings page. Second, translation had to live in the core of the model instead of clipping onto the edge, because I’ve kept bilingual sites running on tools that assumed one language, and I didn’t fancy the reruns.

Then there’s the one that people underrate, and it’s tangled up with not wanting to just theme something. I didn’t want to buy a structure and paint over it. I wanted the site to look like mine, all the way through. Most platforms hand you a skeleton and let you choose the colours, and if you look closely the seams always show, that faint sense that the design stops where the theme’s assumptions begin. I wanted a single visual language running from the homepage hero down to the legal pages, down to the spacing inside a code block. That’s much easier when you own the markup and the CSS from top to bottom, with nothing underneath quietly overruling you.

And the last want is the one that actually tipped me over.

For a developer, the most convincing thing in a portfolio is the software the portfolio itself runs on.

Anyone can list the tools they know. A site you can open up and read, real decisions and real mistakes still sitting in it, makes the case by itself. That alone was enough for me to start.

The bill

Now the part the victory laps leave out. Build your own and you re-solve problems the grown-up platforms and tools handled a decade ago. All of them. No skipping. I wrote the models, I built a proper confirmation dialog after the first cheap inline one turned out buggy and I had to tear it out for a real <dialog>. I paginated the blog index, capped the RSS feed, and built the deployment pipeline.

Every feature is one I make before I can use it. And nobody else is testing this, so the safety net is whatever tests I write. My CI runs against Postgres now for exactly one reason: a couple of bugs slid past on SQLite and only surfaced on the real database, which is a humbling way to get reminded that “passes locally” and “works” are different sentences.

Worth it anyway

For me it was, because the building was the point. It wasn’t a fee on the way to writing or managing content. Every wall I hit turned into something I understand from the inside, instead of a workaround I memorised. The timezone handling, the block system, the way one dumb NULL camped in the featured slot: I know why each of those works the way it does, because I was there when it didn’t.

What I’ve got at the end is a site I can explain all the way down, from the schema to the gap between these two lines. Nothing on it is inherited, nothing is painted over something I’d rather not look at. That’s the thing a portfolio is supposed to prove, and it’s the thing WordPress was never going to let me say. Last post was the tour. This one was the why. Next time I’ll just show you something I made.