CMS Chronicle #00: Why We're Building This Building This

E2E-ROUNDTRIP-1774627983401E2E-ROUNDTRIP-1774618691302We have been building websites since the mid-nineties. Not as a side project. As the thing. We started the first real web agency in Denmark in 1995 — before most people had heard the word. We were the first to do a lot of things, and we carry that history with a quiet kind of pride. We have shipped somewhere north of a thousand sites across three decades — for doctors, retailers, law firms, municipalities, startups that became companies and companies that became institutions. We know what a CMS needs to do because we have watched what happens when it fails to do it.

So why are we building a third one?

We built Site Manager first. Then ODEUM CMS, which still powers hundreds of client sites today. Both were purpose-built for their era — and both taught us something the market couldn’t. This time is different in one important way: @webhouse/cms is open source. Not a product we sell. Not a platform we host. A tool we’re giving back.

“Every CMS we’ve built has been a response to what the previous one couldn’t do. This one is a response to what none of them were ever designed to do.”

Not because the existing options are bad — some of them are remarkable pieces of engineering — but because none of them were built around the specific assumptions we hold about how web content should work in 2026.

The WordPress problem

We built on WordPress for years. We still maintain WordPress sites. It is ubiquitous fo

E2E-ROUNDTRIP-1774627983401

E2E-ROUNDTRIP-1774618691302r a reason: it gave non-technical editors genuine autonomy at a time when that was radical. But WordPress was designed for a world where the developer builds the structure and the editor fills it in. That world still exists. It is just no longer the only world.

The complexity that accumulates in a mature WordPress installation — the plugin dependencies, the PHP version drift, the database that nobody fully understands, the theme that works until it doesn't — is not a failure of WordPress. It is the weight of thirty years of backwards compatibility. We respect that weight. We're just not willing to carry it for new projects.

“WordPress solved 2005's problem perfectly. We need to solve 2026's problem.”

The headless CMS problem

The obvious answer, for the last five years, has been: go headless. Use Contentful, Sanity, Prismic — decouple your content from your rendering. And we did. We used several of them. They are, in many ways, excellent.

But headless CMSes made a quiet trade-off that rarely gets named directly: they moved complexity from the server to the integration layer. You no longer fight the database — you fight the API. You no longer maintain a PHP monolith — you maintain a JavaScript client that talks to a third-party service whose pricing model may change, whose API may version, whose uptime is someone else's SLA.

“A headless CMS is not content infrastructure. It is a content subscription.”

More importantly: every headless CMS we evaluated treated AI as an afterthought. A webhook trigger, maybe. An integration you could bolt on. Not something native to how content is authored, validated, and protected.

What we actually believe

After thirty years of building, and two years of watching AI reshape what it means to write code and content, we have converged on a set of convictions that no existing CMS fully reflects.

• Content should be filesystem-native. JSON files in a /content directory, committed to git, readable by any tool — including AI agents operating directly on the repository.
• AI should be first-class, not bolted on. Generation, rewriting, SEO optimization, and content protection should be built into the engine, not assembled from plugins.
• Human edits are sacred. If a person writes a sentence, no AI should ever overwrite it without explicit permission. Field-level locks. Automatic. Non-negotiable.
• Static output should be the default. The production artifact should be pre-rendered HTML and CSS. No runtime framework unless the developer explicitly opts in. Fast, cheap, resilient.
• Developer experience should be the constraint. If it takes more than sixty seconds to have a working CMS on a new project, the tool has failed.

This is what we're building. We're calling it @webhouse/cms.

The heritage

This is not our first CMS. Before the headless era, we built ODEUM CMS — a custom content management system that powered a generation of our client sites. ODEUM taught us what a CMS actually needs to do at the production level: survive editor mistakes, handle structured data gracefully, and never get in the way of the person who just needs to change a phone number at 9pm on a Friday.

@webhouse/cms is the successor. Rebuilt from scratch in TypeScript, designed for AI-native workflows, with thirty years of production lessons baked into the assumptions.

What the build looks like

We're doing this in public, in phases, and documenting every significant decision in this series.

Phase 1 is the foundation: schema definition, the filesystem/JSON storage adapter, the build pipeline that generates static HTML, the CLI, and a full test suite. Content modeling, persistence, output — the core loop.

Phase 2 is AI integration: a ContentAgent that can generate and rewrite content, a SeoAgent that optimizes across the whole site, hierarchical URL routing, and sitemap generation. And critically: the AI Lock system, which protects human-edited fields at the field level, automatically, with a full audit trail.

Phase 3 is production infrastructure: a Supabase/PostgreSQL storage adapter for team environments, Docker packaging, and a Fly.io deploy pipeline. When Phase 3 lands, this stops being a local tool and becomes something you can actually run in production.

We ship in weeks, not quarters. The first commit is this week. The first real site runs on it shortly after.

This is the CMS we needed thirty years ago. We're building it now.

E2E-ROUNDTRIP-1774618691302

E2E-ROUNDTRIP-1774627983401