It took me 7 years to admit WordPress isn’t the answer to everything

For the best part of seven years, WordPress was my hammer and every project was a nail.

New client? WordPress. Brochure site? WordPress. Ecommerce? WordPress + WooCommerce. Booking system, members area, weird bespoke calculator thing the client sketched on a napkin? You guessed it.

And to be fair, it mostly worked. That’s the trap.

WordPress is genuinely brilliant at being a content management system (CMS). That’s what it was built for. Someone needs to log in, write a blog post, swap out a hero image, add a new team member without ringing me every five minutes – WordPress nails that. Two decades of refinement, a plugin for basically anything, and a back end most clients can navigate. For a content-driven site, it’s still the first thing I reach for and I’m not ashamed of that.

The problem is I kept reaching for it long after the content stopped being the point. These days I start with Web Strategy: the business goal first, then the right tool for it.

“It can do that” is not the same as “it should do that”

This is the bit that took me embarrassingly long to internalise. WordPress can do almost anything. There’s a plugin, a workaround, a clever bit of ACF (great plugin, have used a lot over the years) and a custom post type that’ll get you there. I’ve built some genuinely complex applications on top of it through sheer stubbornness and a lot of functions.php I’m not proud of. Well maybe a little.

Some projects were a bit “plugin overload”.

But every one of those builds had the same smell. I was fighting the platform instead of using it. Bending a publishing tool into an application framework, then spending half the project bolting on plugins to handle things a proper app stack gives you for free: auth, data validation, type safety, a sensible way to handle forms that isn’t held together with hope.

There’s a moment on those projects where you realise you’ve spent three days making WordPress do something that would’ve taken an afternoon in Next.js. That moment used to make me defensive. Now I just take it as the platform telling me I picked the wrong tool.

The shift

What actually changed wasn’t WordPress. It was me getting comfortable enough with other tools that the alternative stopped being scary.

Once I had some solid experience in TypeScript with frameworks like Astro & Next.js and database solutions like Neon & Supabase, the calculation flipped. Bespoke web apps (the price estimators, the ordering systems, the things with real logic and real state) belong on a stack built for applications. Not because WordPress can’t, but because the bespoke route is faster to build, easier to maintain, and doesn’t fall over the moment a plugin updates and decides to ruin your afternoon.

And the funny thing is, admitting this made me better at both. I’m a better WordPress developer now that I’m not asking it to be something it isn’t. When I build in WordPress these days, it’s because the project is genuinely content-led and the client needs to manage it themselves. That’s the sweet spot. That’s the job it’s good at.

So where’s the line?

Roughly how I think about it now:

If the heart of the project is content: pages, posts, things a non-technical person needs to edit then WordPress, every time. It’s a CMS and it’s a great one.

If the heart of the project is behaviour: logic, data, user accounts, anything that feels more like software than a website then that’s a custom build. Next.js and friends, not a pile of plugins doing impressions of an app.

Most projects sit clearly on one side. The trouble only ever came from me trying to drag the second kind onto the first because it was the tool I knew.

Seven years to learn that. Use the right tool for the job which turns out the advice your nan could’ve given you also applies to web development.

Have you ever forced a project into the wrong stack and only admitted it halfway through? Be honest.