Devstars
Blog
Date: 18/04/2026
Stuart WatkinsWhat the Mullenweg blow-up and the wider governance crisis actually mean for any business running a WordPress site at scale, and the three architectural decisions that separate sites that survive platform drama from the ones that don’t.
On 15 April 2026, WordPress co-founder Matt Mullenweg spent several hours venting in the project’s public Slack. He called core output “boring or mediocre crap”, said “the wheels have fallen off”, and admitted WordPress had “spent years doing damage to itself”.
That’s not a tech journalist’s summary. Those are his own words, about the platform he created, posted publicly to the people who build it.
The Slack thread landed on top of an 18-month governance crisis that most people outside the WordPress ecosystem haven’t been tracking. Quick recap:
This isn’t a storm in a teacup. It’s the biggest governance crisis in the platform’s history. If you run a serious website on WordPress, or you’re responsible for one, you need a clear view of what it does and doesn’t change.
Let’s be direct. WordPress still powers roughly 40% of the web. The codebase is fundamentally sound. The update servers are still running. Plugin developers are still shipping. Sites didn’t break on 16 April and aren’t about to.
The drama is about governance, not code. One person controls Automattic (the for-profit company that makes most of its money from WordPress.com), the WordPress Foundation (the non-profit that holds the trademark), and WordPress.org (the infrastructure that distributes updates to every WordPress site on the planet). When those three entities’ interests aligned, the concentration of control looked efficient. When they stopped aligning, there was no mechanism to absorb the shock.
For most businesses running WordPress, none of this is an immediate operational risk. Your site works. Updates still come through. Your developers can still build.
What it does change is the calculation around architectural risk. And this is where most WordPress sites built in the last decade have a problem.
Over 20+ years of custom web development, we’ve seen one pattern more than any other. Sites that survive platform drama, algorithm changes, plugin deprecations, hosting migrations, and ownership transitions share three architectural traits. Sites that struggle are missing at least one.
Most WordPress sites are built by assembling: a commercial theme, a page builder (Elementor, Divi, WPBakery), and 30–50 plugins doing various jobs. That approach is cheap and fast. It’s also fragile.
Every plugin is an external dependency maintained by someone you don’t employ. Every commercial theme locks you into a vendor’s upgrade path. Every page builder adds a rendering layer between your content and your visitors. When one of those breaks, or gets abandoned, or changes its licence terms, your site breaks with it.
Lean custom WordPress builds invert this. Bespoke theme, minimal plugins (ideally under 15), and no page builder between you and the HTML. The trade-off is higher upfront cost and the need for a developer who can actually code. The payoff is a site that’s faster, more secure, and far less exposed to anyone else’s decisions. Our approach to WordPress development is built on exactly this principle.
When we rebuilt the Headmasters site across 56 locations, we reduced the plugin count from 40+ to a handful and dropped homepage load time by 60%. That site has now run without serious incident for eight years across multiple WordPress major versions, including through all the governance turbulence of the last 18 months. The reason isn’t that we’re particularly clever. It’s that we built it to depend on as little as possible.
The WP Engine story is the clearest illustration in WordPress history of what happens when your hosting provider becomes a single point of failure. Thousands of sites lost access to plugin updates overnight because of a dispute the site owners had no part in.
The lesson isn’t “avoid WP Engine”. It’s “understand who controls what”. If your agency owns your hosting account, your domain registration, or your DNS, you don’t really own your site. You own the content. They own the keys.
We now insist, on every client engagement, that the client owns their own domain, their own hosting account, and their own DNS. We manage on their behalf when it helps. But the accounts are in their name. If we vanished tomorrow, or if their hosting provider had a governance blow-up of its own, they’d still have their site. Our secure web hosting service is always provisioned under the client’s own account for exactly this reason.
That’s not a courtesy. It’s a structural decision that has to be made at the start of the relationship.
The most overlooked architectural decision is how your content is stored. Sites built with heavy page builders store their pages as serialised shortcodes, custom post meta, or proprietary block formats. Migrate away from the builder and the content breaks. Migrate to a different platform entirely and the content is often unrecoverable without a rebuild.
Sites built with the native WordPress editor, standard blocks, and a clean content model are portable. You can export, you can migrate, you can move to a different CMS if you ever decided to. The data belongs to you.
This matters more in an era of platform uncertainty. Cloudflare launched EmDash, a ground-up WordPress competitor, in early 2026. It won’t be the last. Businesses that can move when they need to have optionality. Businesses that can’t are stuck.
On 15 April, longtime WordPress user David Lewis published “The Case for WordPress” on Randomwire. It’s worth reading if you want a thoughtful perspective from someone who’s been on the platform since 2004.
His core argument is that WordPress’s founding promise, that you should own your corner of the web, matters more now than at any point since 2003. The alternative people drift toward, Substack, Squarespace, Shopify, Wix, is rented land. You don’t own the platform, the audience, the data, or the long-term archive. You’re a tenant.
He’s right. And the architectural decisions above are what turn that ownership promise from a slogan into something real. A lean custom WordPress site on hosting you control with portable content is genuinely yours. A template site on managed hosting with everything in a page builder’s proprietary format is rented space that just happens to be built on open-source software.
The difference matters most when things go wrong. And in an era where the platform’s founder is publicly criticising his own project, where contributors are being banned for asking governance questions, and where a rival federated repository has just launched, things are going wrong more often than they used to.
Three audits, in order of priority.
1. Architecture audit. Count your active plugins. Check whether you’re using a commercial theme or page builder that controls your content format. Identify where custom code could replace plugin dependencies. Any plugin count over 25 is a yellow flag. Over 40 is red. The Headmasters rescue was 40+; we’ve seen worse.
2. Ownership audit. Log into your domain registrar, your hosting provider, and your DNS. Confirm the accounts are in your name, not your agency’s. If they aren’t, fix it this month. This one change insulates you from most platform-level and agency-level drama.
3. Portability audit. If you had to move your site to a different CMS in 90 days, could you? What would break? What would survive? This isn’t about planning to leave WordPress. It’s about knowing whether you could if you had to.
These audits cost nothing but a couple of hours of developer time. They’re the cheapest insurance against governance drama, platform instability, or any other variable outside your control. If you’d rather have fresh eyes on it, our digital marketing team runs this as part of a broader site health review.
The Mullenweg rant isn’t the story. It’s a symptom of a governance structure that was designed for a project a fraction of WordPress’s current size, run by a founder whose interests were assumed to align with the community’s. That assumption held for 20 years. It’s stopped holding, and the mechanisms to absorb the shock don’t exist yet.
Where does this go? Three plausible scenarios, in no particular order:
We don’t know which one wins. Nobody does. What we do know is that the businesses best positioned to navigate any of those outcomes are the ones who built their sites on solid architecture, who own their infrastructure, and who can move if they need to.
The good news is that those are the same architectural principles that produce faster, more secure, more conversion-focused sites regardless of what happens at the platform level. The Mullenweg drama doesn’t change what good looks like. It just makes the case for it more urgent. It’s also worth noting that the same forward-thinking approach applies to search: businesses investing in GEO and AI search visibility now are building the kind of durable digital presence that outlasts any single platform’s governance drama.
WordPress is still the right answer for most businesses. But the difference between a WordPress site that survives platform drama and one that doesn’t is architectural, not philosophical. Lean builds, owned infrastructure, portable content. Everything else is detail.
If you’re not sure where your site stands, we offer an architectural audit for existing WordPress sites. No sales pitch attached. Just a clear read on where you are and what, if anything, needs attention.
Devstars has been building and rescuing WordPress sites for complex businesses since 2003. We specialise in lean custom builds for scale-ups, enterprises, and established brands who need their digital infrastructure to outlast the platform drama of any given quarter.
Tell me what you’re trying to fix. Half an hour, no pitch, no slide deck.
If we’re the right fit we’ll talk about what’s next. If we’re not, I’ll point you to someone who is.
