The Tweet That Made Me Think About Leaving WordPress (And Why I Didn't)
Saw a tweet last week: someone migrated 800+ articles off WordPress to static HTML, managed entirely through Claude Code. No database, no plugins, no admin panel, just markdown files and an AI agent editing them directly.
A few months later, they moved back to WordPress.
That caught my attention because I've been down this exact road, and I ended up somewhere different than either "stay on WordPress" or "go full static with an AI editing raw files."
Why static-with-AI-editing burns people
The pitch is obvious: no plugins to patch, no database to get hacked, no PHP runtime eating a CPU core because a sort comparator got rebuilt on every render (yes, that's a real thing that happened to me, more on that some other time). Just files. Fast, cheap, simple.
Except "simple" breaks down the second you want any of the things a CMS normally gives you for free: draft/publish workflows, media management, scheduled posts, someone non-technical adding content without opening a terminal. When your only interface is "ask an AI agent to edit markdown files," you've traded a GUI for a chat window, and that's a worse trade than it sounds like at 2am when you just want to fix a typo.
That's the wall this person hit. It's not that static sites are bad. It's that static-plus-raw-files-plus-AI-agent isn't actually a content management system. It's a workaround wearing a CMS costume.
What we do instead: EmDash
We hit the same tension building EmDash. The answer wasn't "pick static or pick a database," it's "keep the speed of static hosting but put a real CMS layer on top of it."
EmDash runs on Cloudflare Workers and Pages for the actual site delivery, fast edge hosting, no origin server to babysit, but content lives in Cloudflare D1 for structured data and R2 for media, managed through an actual admin interface. You get the editing experience people expect from a CMS (drafts, scheduling, media library) without dragging a full WordPress-plus-MySQL stack back into the picture.
Best of both: static-site performance and cost, CMS-grade editing experience.
The WordPress problem this actually solves
WordPress isn't slow because of the CMS concept, it's slow and risky because of everything bolted onto it. Every plugin is an attack surface. Every plugin is also a thing that can silently break on update.
Case in point: there's a currently unpatched privilege escalation CVE in ThriveCart, a plugin a lot of WordPress sites run for checkout and payments. That's not a hypothetical. That's a real, live vulnerability sitting in production sites right now because the plugin ecosystem that makes WordPress powerful is the same ecosystem that makes it fragile.
Add up the cost side too: managed WordPress hosting that can actually handle traffic runs $20-100+/month before you touch premium plugins, and you're still patching a PHP application with a public-facing admin panel that's a permanent target.
It's not just blogs
This isn't a "static site generators are neat for blogs" post. We're running AutoVault.sh, full e-commerce with a real database, entirely on Cloudflare, for about $5 a month. Product catalog, checkout, order data, all of it on the same edge infrastructure, no traditional server, no WordPress, no plugin graveyard waiting to get exploited.
Even email marketing runs the same way now. Our MMail project sends campaign email straight from Cloudflare Workers, so the entire stack, content, commerce, and email, lives on one platform with one bill and one security model instead of three separate systems each with their own patch schedule.
The actual lesson
The tweet's author framed it as static vs. WordPress, and went back to WordPress when static-with-AI-editing hit its ceiling. But that's not really the choice. The real fix isn't "give up and go back to the database-and-plugins model," it's "keep the edge-hosted speed and cost, and put a real content layer on top of it instead of asking an AI to hand-edit files."
You don't have to choose between fast/cheap and manageable. You just have to stop assuming a CMS requires a server.