If you’ve been following my blog, you’ve already seen a post about fixing WordPress after a botched update. It’s no coincidence that I know that topic well — and it’s exactly why, after years of working with the platform, I’ve deliberately moved away from it for new projects. Not out of whim or fashion. For concrete, recurring reasons, which I’ll lay out plainly.
Let’s be fair up front: WordPress isn’t “bad”
Before anyone reads this as a hit piece — WordPress powers a massive chunk of the internet, and for a lot of use cases (large content-heavy sites, blogs run by multiple non-technical people, big editorial teams) it still makes sense. It’s not a bad system. It’s simply not the right system for what I build — and my clients usually need something different than what WordPress offers by default.
Reason 1: Every plugin is someone else’s code, and I’m the one accountable for it
A typical WordPress site runs 15-30 plugins. Each one is code written by someone else, of unknown quality, updated (or not) at an unknown pace, with an unknown history of security holes. When you build a site on WordPress, you’re effectively vouching for the work of dozens of anonymous teams you’ll never meet. I’d rather write (or deliberately select, with AI as an assistant) code that I actually understand line by line.
Reason 2: Security becomes a game of Russian roulette with automated bots
WordPress is so popular that it’s become a primary target for automated attacks scanning the internet for outdated plugins. It’s not a question of “if,” but “when” — an unpatched site will eventually get scanned and, if it has a vulnerability, attacked. Keeping on top of this requires constant vigilance, which is easy to neglect, especially for clients who “don’t have time” for regular updates.
Reason 3: Performance you have to keep fixing, instead of having it from the start
A fresh WordPress install runs decently. After adding a form plugin, an SEO plugin, a caching plugin (to fix the slowdown from the previous plugins), a page builder, and a booking system — the site starts to resemble a car with five extra engines bolted on the side to make it go faster. You can optimize it, but it’s a constant uphill battle, instead of building something lightweight from the first line of code.
Reason 4: Flexibility that’s often illusory in practice
WordPress markets itself as “do anything” — and technically that’s true, but it often means stitching together plugins that were never designed to work with each other. Something that, in my approach (Astro, Next.js, custom code), is one coherent architectural decision, on WordPress often becomes a compromise between three plugins, each covering 80% of what you need, with the rest patched in by hand.
So why do I still touch WordPress sometimes?
Because business reality doesn’t always ask for my preferences. If a client already has a working WordPress site, is happy with its features, and the problem is specific (site broke after an update, it’s slow, someone hacked it) — I fix it without complaint. Not every situation is an opportunity to convince someone to rebuild their whole site from scratch on a different stack, especially if what they have is already serving them well enough.
The line is simple: I fix existing WordPress sites, but I build new projects differently. That’s not inconsistency — it’s just matching the tool to the situation, not to my own preferences.
What I do instead
New projects with me are built on modern, lightweight technologies (Astro, Next.js, a custom backend), without a layer of dozens of third-party plugins sitting between your site and the server. The result: a site that loads faster, has a smaller attack surface, and where I understand every piece — because I either built it myself, or built it with AI under my own supervision, not installed it from an unknown author on the internet.
The key philosophical difference: such sites don’t ship any unnecessary JavaScript by default (zero JS by default). Interactions — menu, accordion, form — are added one by one, exactly where they’re needed, instead of loading a global runtime on every page. That’s the exact opposite of the WordPress model, where every plugin adds its own code, which you then have to clean up with more optimization plugins.
On top of that, a coherent design system: one color palette, two fonts with clearly assigned roles, a spacing rhythm — the whole thing looks intentional by default, even after you replace half the content. It’s a series of small, enforced constraints that make a site look designed — instead of bolting together dozens of plugins and hoping for the best.
Have a WordPress site and wondering whether it’s worth rebuilding or just fixing what’s there? Tell me what’s going on with it — I’ll give you an honest answer about which path makes sense for you.