I Was There When WordPress 1.0 Launched. Emdash Gives Me That Same Feeling.

I built one of the leading WordPress agencies in Switzerland. Twenty years later, a new CMS is making me feel like it's 2004 again.

In 2004, WordPress 1.0 came out and I started a blog the same week. No strategy. No business plan. I just liked it. The software was rough, the community was small, and something about it felt like the future.

By 2005 I was building client websites with it. By 2010 I'd built one of the leading WordPress agencies in Switzerland. WordPress wasn't the only tool. We did plenty of work on Shopware and other platforms. But WordPress was the one that kept pulling me back.

I'm telling you this because I felt that same pull last month. And I haven't felt it in years.

What changed in 2026

Not WordPress. WordPress is fine. It still does what it does.

What changed is that agentic development got real. Not the hype version from 2024 where every SaaS added a chatbot sidebar. The actual version, where AI writes production code and manages systems. That shift happened about three or four months ago when tools like Claude Code and Codex crossed a line. The code they produce went from "interesting demo" to "I'd ship this."

Once you've worked that way, going back to a CMS that was designed for humans clicking through admin panels feels slow. Not broken. Slow.

Then Cloudflare launched Emdash

April 2026. My first reaction was skepticism. I've heard "WordPress killer" enough times to ignore it on reflex.

But Emdash isn't trying to be a better WordPress. It's built for a different era. Joost de Valk, the creator of Yoast SEO, put it well in his review: "This isn't a CMS with AI features added on top. It's a CMS where AI is a first-class builder." Coming from the person who shaped how millions of WordPress sites handle SEO, that carries weight.

The part that made me actually install it: the entire CMS is designed so AI agents can operate it directly. Not through some API wrapper. Through an MCP server that tools like Claude talk to natively. Create content types, manage entries, configure the site, deploy. No admin panel required.

It runs on Cloudflare Workers. No PHP. No server sitting idle waiting for visitors. Your site runs at the edge, in the data centers closest to your users.

It's built on Astro, which handles the balance between developer experience and clean output better than anything else I've used.

Saturday morning with a new CMS

I set up emdash.solutions on a Saturday. Node 22 (not 24, that breaks better-sqlite3 on macOS). npm install. Dev server up. Admin at localhost:4321/_emdash/admin.

The admin felt familiar. Not a WordPress clone, but built by people who understood what makes WordPress's admin work. Passkey authentication instead of passwords. Portable Text instead of HTML stored in a database. TypeScript instead of PHP.

Content modeling is where it gets interesting. You define collections in a seed file. The CMS generates your types, builds the admin UI, and handles migrations from that single source of truth. If you've ever wrestled with ACF field groups in a GUI that doesn't version-control, you know why this matters.

The frustrations are already building

I want to be honest about this because the current version of this post was too polished. Real talk.

Local dev feels pointless. If I'm deploying to Cloudflare Workers, why am I running a local Node server with SQLite? The production environment is D1 and R2. The local setup is a different runtime entirely. I'm not sure this workflow makes sense.

Getting content from Claude Code to production is not smooth. I draft in Claude Code. I want that content on the live site. The path to get there involves seed files, CLI commands, and manual deployment steps. It should be simpler.

The CLI has bugs. Known issues, apparently. Seed validation fails in ways that aren't obvious. For a tool that's supposed to be the primary interface for AI agents, this needs to be solid.

The plugin ecosystem is empty. Not small. Empty. Need a form builder? Build it yourself. Need e-commerce? Integrate something external. If you're used to the WordPress plugin directory, this is a shock.

The community barely exists. Some Reddit threads. A small Discord. People are still figuring out if this is serious.

The MCP server doesn't work on Cloudflare Workers. The endpoint is there. It returns 500 with an empty body. Bearer token auth crashes the entire API. I filed an issue. Session-based auth through the admin UI works, but if you want to connect Claude Code to your live site and manage content programmatically, you can't. Not yet. For a CMS that sells itself as "agent-native," this one stings.

Updating content from code is painful. Right now my workflow for publishing a post is: edit a seed file, generate SQL, push it to D1 via Wrangler. That's not a content workflow. That's database administration.

Why I care anyway

Because for a v0.1.0, this is much better than I expected. Much better.

And I'm clearly not the only one who thinks so. Ten days after launch, the GitHub repo has nearly 9,000 stars and almost 700 forks. Over 440 issues filed. More than 20 open pull requests from external contributors. For context, most new CMS projects are lucky to hit 500 stars in their first year.

The people contributing aren't hobbyists testing a toy. Joost de Valk, the creator of Yoast SEO (the plugin that runs on millions of WordPress sites), already has two pull requests merged: per-collection sitemaps and breadcrumbs. Other developers are building AT Protocol OAuth, SMTP plugins, Node.js plugin isolation. Contributors from China, Brazil, across Europe. The WordPress diaspora is showing up, and they're bringing real code, not just opinions.

That matters. WordPress didn't win because it was the best software in 2004. It won because developers showed up and built on it. The same pattern is starting here, except faster.

The architecture is right for where the web is going. Every WordPress developer has that story about the plugin vulnerability that took down a client site at 2am. Emdash sandboxes plugins in isolated Workers with explicit permissions. The plugin literally cannot access anything you haven't granted it.

The AI integration is the real draw for me. I pointed Claude at the MCP server locally and it created content types, populated entries, and configured the site without me opening the admin once. When you build sites for clients every week, that changes how you think about project timelines. Yes, the remote MCP is broken right now. But the architecture is there. When it works, this becomes a CMS you talk to instead of click through.

And the performance. There's no PHP process to spin up. No database query to wait for. The response comes from the nearest Cloudflare edge node. It's fast in a way that WordPress will never be without a caching layer bolted on top.

The parallel to 2004

WordPress 1.0 was rough too. I remember the bugs. The missing features. The tiny community. The plugin directory was empty. The editor was basic. Half the things you needed, you had to build yourself.

Sound familiar?

But the foundation was right, and the people building it understood what the web needed. Within two years, the plugin ecosystem exploded. Within five, it was the default choice for client websites. The developers who got in early shaped the platform.

I see the same pattern with Emdash. The foundation is right for 2026. Serverless. Structured content. Edge delivery. Agent-native. These aren't buzzwords when you've spent twenty years dealing with the problems they solve.

I'm building this site on Emdash to find out if the pattern holds. Not for client work yet. Just to hit the walls, file the bugs, and form opinions from real use. I already filed my first issue ten days in. That's how you build a relationship with a platform.

I'll write more as I go. What works, what breaks, what's missing. If you've been in the WordPress world long enough to remember the early days, you might recognize what's happening here.

Next up: Emdash vs WordPress for agency work. Not a spec sheet. What it's actually like to build and maintain a site on each.

No comments yet