I’ve been building on WordPress since 2008. Back then, it was a blogging platform people used to post travel diaries and movie reviews. Today it powers roughly 43% of the web, and I still reach for it on most projects. That fact surprises some developers. It doesn’t surprise me at all.
I’m not a WordPress evangelist. I’ve shipped production apps in Laravel, built SPAs in Vue.js, and spent the better part of the last five years working on WordPress plugins at a product company where our installs ran into the millions. I know this platform’s strengths and I know its baggage. This post is about why WordPress development in 2026 is still a genuinely good choice — and when it isn’t.
The Ecosystem Argument Is Not Hype
When developers dismiss WordPress, they usually underestimate one thing: the ecosystem. Not just plugins — the entire surrounding infrastructure of tooling, hosting, community knowledge, and integrations that has accumulated over two decades.
ACF Pro alone has changed how I build content-managed sites. Before Flexible Content fields and block registration via acf_register_block_type(), you were either hammering custom meta boxes together manually or paying for a page builder that generated inline styles nobody wanted to maintain. Now I can define a complex block schema in PHP, register it, and hand a structured editing interface to a client in an afternoon.
WooCommerce is another one. I hear a lot of “just use Shopify” and yes, sometimes Shopify is the right answer. But when a client needs custom pricing logic tied to user roles, or a checkout flow that integrates with a bespoke ERP, or a multi-vendor marketplace that doesn’t fit a SaaS pricing tier — WooCommerce gives you the hooks. Literally. woocommerce_checkout_process, woocommerce_cart_calculate_fees, the REST API, webhooks. The surface area for customisation is enormous.
The Developer Experience Has Actually Improved
I remember when “WordPress development workflow” meant FTP-ing files to a shared host and refreshing the browser.
Today my standard setup is Local (the app, not a XAMPP stack), Composer for dependency management, WP-CLI for everything from database operations to plugin scaffolding, and Git hooks that run PHP_CodeSniffer against WordPress coding standards before a push goes out. It’s a real development workflow.
# composer.json snippet for a modern WordPress project
{
"require": {
"php": ">=8.1",
"johnpbloch/wordpress": "^6.5",
"wpackagist-plugin/advanced-custom-fields": "^6.0",
"vlucas/phpdotenv": "^5.5"
},
"extra": {
"wordpress-install-dir": "wp",
"installer-paths": {
"wp-content/plugins/{$name}/": ["type:wordpress-plugin"],
"wp-content/themes/{$name}/": ["type:wordpress-theme"]
}
}
}Managing WordPress as a Composer dependency, keeping wp-config.php out of the web root, loading environment variables from a .env file — this is standard practice now. It took the community a while to get here, but it got here.
WP-CLI deserves its own mention. Seeding test data, running search-replace across a database after a domain migration, managing users, flushing caches, running cron jobs manually during debugging — I use it every single day. Any developer who tells you WordPress doesn’t have good CLI tooling hasn’t used WP-CLI properly.
The Block Editor Is Growing Up
Gutenberg’s early versions were unstable enough that Classic Editor stayed in my default plugin list for longer than I expected.
That’s changed. Block development with @wordpress/scripts is now clean and predictable. Server-side rendering for dynamic blocks works exactly as you’d expect. The Full Site Editing features — block templates, template parts, global styles — are actually usable in production. I shipped a full FSE theme for a client last year and the content team loved it. They could rearrange header layouts without calling me. That’s the goal.
The architecture isn’t perfect. The JavaScript dependency on React means your block build pipeline carries that weight. If you’re building twenty custom blocks for a complex editorial product, you’ll feel it. But for the typical content-managed site or marketing platform, it’s well within reason.
The Criticisms That Are Legitimate
The WordPress codebase has accumulated eighteen years of decisions that made sense at the time and look awkward now. The options table is a classic example — global options mixed with plugin-specific transients mixed with serialised arrays mixed with things nobody remembers putting there. On a busy site, autoloaded options alone can hit 4MB of serialized data on every request.
Performance out of the box is mediocre. A default WordPress install with a theme and ten plugins hitting MySQL on every request is not fast. You need a caching layer — object cache via Redis or Memcached, page caching via something like WP Rocket or server-level full-page cache, and you need to be deliberate about plugin selection because a badly written plugin can add a dozen database queries to every page load. This isn’t optional, it’s expected maintenance.
The plugin ecosystem has a quality problem. There are 60,000 plugins in the repository and maybe 2,000 of them are things I’d put in a production site. The rest range from “fine but abandoned” to “actively harmful.” Knowing which is which requires experience. That’s a real barrier.
WordPress vs Headless CMS: The Honest Comparison
Every few months a client asks whether they should go headless. My answer is almost always no.
If you’re building a content-heavy marketing site and your team knows WordPress, going headless with Sanity or Contentful and a separate Next.js frontend adds complexity without a proportional benefit. You’ve split your deployment, doubled your infrastructure concerns, and introduced a content preview workflow that is genuinely painful to get right. For most sites, that’s not a good trade.
Where headless makes sense: when your frontend team has strong React or Vue expertise and no WordPress experience, when you need content delivered to multiple surfaces (web, mobile app, kiosk, whatever), or when your content model is so structured and complex that a general-purpose CMS would fight you at every step.
WordPress itself can go headless — WPGraphQL is solid, the REST API is decent — but if you’re going headless anyway, there are purpose-built tools that do it more cleanly. I’m not going to pretend otherwise.
For why I use WordPress: the majority of the work I’ve done, and the majority of what I see teams needing, fits squarely in the category where WordPress’s traditional, server-rendered, plugin-supported model is faster to build, cheaper to host, and easier to hand off than a decoupled architecture. That’s just the reality of the market.
What Changed My Mind (When I Was Starting to Drift)
A few years ago, while working at a WordPress product company, I spent about eighteen months building on top of WordPress at a scale I hadn’t dealt with before. Plugins with over a million active installs. Support queues where a single bug could affect thousands of sites simultaneously. Performance testing on shared hosting environments where you couldn’t assume Redis. Plugin conflicts with code you’d never seen.
It was the kind of environment that exposes every assumption you had about a platform. What stuck with me wasn’t disillusionment — it was a much sharper sense of what WordPress handles well and where it falls apart. WordPress’s hook system, the add_filter / add_action architecture, is genuinely well-designed for a product ecosystem. The ability for third-party code to modify behaviour without touching core files, the consistency of the admin UI APIs, the way user capabilities integrate with plugin permissions — these aren’t accidents. They’re the result of a platform that has been battle-tested at enormous scale for a long time.
I also came away with a sharper eye for what WordPress is bad at, which made me a better judge of when to use it.
How I Evaluate Whether to Use WordPress
When I’m evaluating whether WordPress is right for a project, I’m asking a few specific questions.
Who maintains this after I’m done?
If the answer is “a small internal team with mixed technical ability” or “the client themselves,” WordPress wins almost every time. The admin UI is familiar. Plugins extend functionality without code changes. There’s a WordPress developer available in almost every market if they need future help.
Does the content model map to WordPress naturally?
Posts, pages, custom post types, taxonomies, and custom fields via ACF cover an enormous range of content models. If I’m reaching for those and they fit the data, I’m not fighting the platform. If the data model is fundamentally relational in a way that screams “this needs a proper database schema,” I’ll reach for Laravel instead.
What’s the performance budget?
WordPress with proper caching can absolutely hit the performance numbers most sites need. But if you’re building something where time-to-first-byte is critical at high traffic and you can’t run a full-page cache (dynamic, user-specific content on every request), you need to be realistic about what you’re signing up for.
The Practical Takeaway
Choosing WordPress in 2026 means accepting a codebase full of old decisions, a plugin ecosystem you have to curate carefully, and a performance baseline that needs active maintenance. What you get back is ecosystem depth no other CMS has matched, a client handoff that works, and tooling — WP-CLI, ACF, Composer — that has finally caught up to how you’d expect to work.
Most WordPress frustration comes from inheriting someone else’s shortcuts — themes with 400 lines of CSS injected via wp_head, plugins abandoned in 2019, a database full of orphaned post meta. That frustration is real. It’s just not WordPress’s fault.
If you work the way you’d work on any other serious project, WordPress gets out of your way and gives you a platform with enormous reach, a vast ecosystem of quality tooling, and a client handoff story that nothing else matches. That’s why I still choose it.
If you’re evaluating WordPress for a project right now, check my work page for examples of what this looks like in practice.
