I'm finally done defending WordPress bloat and testing Statamic instead

For nineteen years, WordPress has helped pay my bills. It's the platform most clients ask for by name, whether or not they understand why, and I've built more WordPress sites than I could count. But if I'm honest with myself and honesty is meant to be the point of this blog. I believe WordPress has never really been for developers.

It's built for the widest possible audience of non-technical users, and every decision in its architecture reflects that. Which means every time I sit down to build something properly, I'm working against the grain of the platform rather than with it.

Statamic works differently, and the difference matters more than most agencies will admit.

What actually prompted this

This isn't a purely theoretical gripe. I've recently been doing work for a client who, like a lot of businesses, spreads development work across multiple developers. It's a sensible approach on paper, but in practice, on a WordPress build, it means every developer who's touched the site has reached for their own preferred plugin to solve a problem and nobody's gone back to check whether a solution already existed. The result is a site running several plugins that do, more or less, the same job. Layered on top of each other. Occasionally conflicting with each other.

Nobody did anything wrong, exactly. It's just what happens to WordPress sites over time when more than one person builds on them without a single person accountable for the whole. And it crystallised something I'd been circling for a while that the problem isn't really WordPress, it's what WordPress's architecture permits and what it permits, eventually, someone will do.

The control problem

WordPress gives you a database full of post types, a plugin ecosystem that patches over its own gaps, and hooks that override other hooks in ways that become genuinely hard to reason about once a site has been live for a few years. I've inherited enough WordPress builds to know that "it works" and "I understand why it works" are two very different states, and the gap between them is where technical debt lives.

Statamic, built on Laravel, gives me a codebase I understand end to end. Content can live flat-file or in a database. Templating is clean and predictable. There's no plugin arms race, because most of what you'd reach for a plugin to do, you can simply build, once, in a way that fits the site rather than bolting on top of it.

That's not a nostalgic developer preference for "clean code." It has a direct, practical consequence. When I have full control over how a site is built, I can build it to actually fit the client, rather than fitting the client to whatever WordPress happens to make easy that week.

Why this isn't just a developer's luxury

Something that easy to lose in a post like this is that control isn't just satisfying for me, it's what the client is actually paying for, even if they'd never phrase it that way.

A site built with full control tends to be faster, because there's no dead weight from plugins doing 80% of what you need and 20% of what you don't. It tends to be more secure, because the attack surface is whatever I've deliberately built, not whatever thousands of third-party plugin authors have shipped over the years. And it tends to be easier to maintain, because when something needs to change, I'm not hunting through someone else's abstraction layer to find where to make the change. I already know, because I built it.

Clients feel all of this, even when they can't articulate the cause. They feel it in how quickly a site loads, in how rarely something breaks after an update, in how fast I can turn around a change when they ask for one. That's the real argument for Statamic, not "it's a nicer stack," but "the control it gives me becomes the flexibility you experience."

Speed you don't have to fight for

Take performance, because it's the clearest example. On WordPress, speed is something you bolt on and then defend. A caching plugin here, an image optimiser there, constant vigilance every time you or a client adds a new plugin that quietly reintroduces the problem you just solved. It's never finished. It's maintenance.

On Statamic, a standard page render doesn't touch a database at all, the content can live in flat files, so speed isn't a plugin you install, it's just how the site behaves by default. That's not a minor technical footnote. It's the difference between a fast site and a site that's fast today, until the next update changes that.

It's also, frankly, the standard justification developers use for charging more for this kind of build and I think it's a fair one. A fast, low-carbon, genuinely SEO-friendly site isn't an add-on service; it's what you get by default when the architecture doesn't fight you. Set that against a typical plugin-heavy WordPress build, quietly accumulating technical debt with every update, and the comparison isn't close.

I'll admit that Statamic does cost more than WordPress

I'll say the quiet part too. Statamic costs more than WordPress upfront. WordPress is free, Statamic isn't, and I'm not going to pretend otherwise.

But "free" is doing a lot of work in that sentence. In my experience, free is often the most expensive platform of all once you actually total up the cost of plugin sprawl, the premium extensions that stack up, the hours spent firefighting an update that broke three plugins at once, and the ongoing maintenance that never really stops. WordPress's sticker price and its real cost are two very different numbers. Statamic's are much closer together, you pay more at the start and considerably less in the years after, particularly for a bespoke build where you're not fighting the platform's architecture just to make it do something specific.

Practising what I preach

There's a limit to how convincingly I can make that argument from the sidelines, though. My own site, thelonedeveloper.co.uk, currently runs on Jigsaw, a static site generator built on Laravel Blade. It's fast, it's simple, and there's nothing wrong with it. Which is exactly why it's the right site to experiment on.

I'm moving it to Statamic, not because Jigsaw is broken, and not because I've got a client project riding on it. I want to live with Statamic the way my clients eventually will, managing content through it day to day, hit its rough edges, work out where it genuinely outperforms a static build and where it doesn't. I don't want to pitch a platform to clients that I've only read about and tinkered with. I want to have actually lived in it.

If it holds up the way I expect, Statamic becomes a proper offering alongside WordPress and Drupal. Not a replacement for either, but another tool suited to a specific kind of client, the one who wants more control over their content model, better performance, and a site built by someone who understands every layer of it, rather than one assembled from parts nobody fully understands any more.

That's the whole pitch, really, not that "Statamic is better." Just, when the person building your site has full control over how it's built, that control doesn't stay with the developer. It ends up in your hands too.

I'll be documenting the migration as I go, including the good, the awkward, and whatever breaks along the way.