I've worked with WordPress for over 15 years. As a freelance developer in Bath and Bristol, I do WordPress work for clients regularly - performance, troubleshooting, security, hosting. But I'm wary of writing custom code in it, and I won't build application logic on top of WordPress. Mostly. Here's why, and what "mostly" means.
WordPress Is Great at What It Does
I want to be clear: WordPress is a genuinely good piece of software for what it's designed to do. Content management, publishing, editorial workflows - it's mature, it's battle-tested, and there's a reason it powers a huge chunk of the web. A blog, a marketing site, a brochure site with pages and posts and a handful of well-chosen plugins - that's WordPress doing what it's best at. If that's what you need, use it. I recommend it to clients regularly and I do WordPress work myself.
The issue isn't WordPress. It's trying to make it do things it wasn't built for. WordPress is a CMS, not an application framework - and it doesn't bend into shape well when you push it beyond content management. There's no proper MVC structure, no dependency injection, no clean separation between business logic and presentation. Everything hangs off hooks and filters, global state is everywhere, and the data model (posts and meta) gets bent into shapes it was never meant for. You can make it work - people do - but the code you end up with is harder to read, harder to maintain, and harder to hand to someone else.
Testing Is Where It Really Hurts
This is the sharp end. In Laravel or Symfony, I write automated tests, run them in CI, and have confidence that changes haven't broken anything. The frameworks are designed for it: dependency injection makes mocking straightforward, the database layer is isolated, and tests run fast.
In WordPress, automated testing is painful. Tests need a full WordPress bootstrap and a database. Global state makes it hard to isolate anything. There's no dependency injection to mock against, so you're always testing against the real thing. The practical result is most custom WordPress code isn't meaningfully tested - and when something breaks, debugging means "disable plugins one by one and see what happens." That's not QA. For anything with real business logic behind it, I want proper tests and proper confidence.
The Plugin Trap
"Just write a plugin" sounds simple, but a custom plugin lives in a shared environment with every other plugin, the theme, and WordPress core. You can't control that environment the way you can with a standalone application. Plugin conflicts, upgrade anxiety, WordPress core changes breaking things - I've written about the perils of plugin stacking in more detail. The deeper issue is that each plugin you add (or write) increases the surface area for things to go wrong, and makes the whole system harder to reason about and test.
And then there's the upgrade question. WordPress core updates regularly. Plugins need to keep up. A custom plugin you wrote three years ago may quietly break after a core update, and unless you've got tests (see above), you might not know until a customer reports it.
What I Do Instead
For anything that's fundamentally an application - dashboards, APIs, workflows, integrations, complex business logic, user-generated content - I build in Laravel or Symfony. Proper structure, proper tests, proper deployments. One codebase you control, with no dependency on a plugin ecosystem or WordPress core release cycle. It's more productive, more maintainable, and results in better software.
For CMS work - content-heavy sites, blogs, marketing sites where non-technical editors need to update content - WordPress with a lean set of off-the-shelf plugins is often the right answer. It's great at that job, and trying to replace it with a framework for pure content management would be over-engineering. The distinction is simple: use WordPress for what it's built for, and a framework for what it's not. I help clients with WordPress performance, security, and troubleshooting regularly.
What "Mostly" Means
It's not a hard-and-fast rule. When WordPress or WooCommerce is the right tool, I'll write custom code to support it - API connectors, data sync tools, a custom shipping calculation, relatively small bits of functionality that keep the site doing its job well. I've built plenty of those over the years. The key is keeping things contained: clean, self-contained code that doesn't tangle itself up with other plugins or create a maintenance headache. What I'm wary of is complexity, tight coupling, and code that's going to be fragile when WordPress or another plugin updates.
What I won't do is build your ground-up product on WordPress, or suggest you solve a complex requirement by stacking plugins until it sort of works. For that kind of work, a framework like Laravel or Symfony is more productive, more testable, and a better foundation. If you're not sure which direction makes sense for your project - whether you're in Bath, Bristol, Wiltshire, or anywhere in the UK - let's talk it through.