The CMS Tax

Up until recently, "a client wants a marketing site" has been synonymous with "the client needs a CMS." The client needs to edit copy, and they are not going to open a code editor, so they should use a CMS (our choice is typically Sanity). This was the standard decision at our agency for a long time.

I think this is slowly changing, mostly thanks to AI agents. Indeed, Lee Robinson recently wrote about moving cursor.com off of Sanity, and Joost de Valk has made a similar argument from the WordPress world: many sites do not actually need a CMS so much as they need a way for normal people to change the website. What a CMS abstracts away—editing the codebase—is becoming a lot more accessible than it used to be.

Yes: clients still need to change headlines, add pages, swap logos, update CTAs, fix typos. But the interface for doing that may no longer need to be a CMS. Because agents (typically interfaced through some simple, non-technical tool like @Cursor or @Claude Slack agents) make the codebase itself a more usable interface than a CMS is.

Say the client wants to update their navbar. If the navbar lives in a repo, an agent can find it, change the link, and open a PR. Assuming the codebase is architected with type safety in mind, an agent-driven change like that is more reliable than a human-driven one in a CMS.

Same goes for entire pages: if a pricing page lives in a repo, an agent can update the copy, duplicate a section, or build a brand new component without first asking whether the CMS has a "PricingFeatureGridV3" block that happens to support that particular combination of fields. It can do this because the codebase is a more efficient interface for its user (an agent) than a CMS is for its user (a human).

On the other hand, a human navigating a traditional CMS needs to know the ins-and-outs of the CMS's content model. This is fine if they're well-trained or willing to put in the time. But oftentimes the learning curve to do something relatively simple can be surprisingly steep.

Moreover, an agent trying to navigate a CMS usually falls short pretty quickly—it can see a fetch call but not the thing being fetched (this is not the case in Markdown-based CMSes, which I am more bullish on). The actual content is behind auth, represented inside some proprietary content model, edited through an admin UI built for humans clicking around. Which leads to a goofy situation: an agent can refactor the entire frontend to support a new feature, but can't easily change "Contact" to "Contact Sales" because that nav item lives in Sanity.

Many CMSes claim they're becoming agent-native, introducing APIs and SDKs and MCPs (all the acronyms 😎) to make it easier for agents to edit content. But in my experience, compared to a simple grep-and-replace, these MCPs are less reliable and more expensive (in terms of time and tokens).

A CMS used to be the interface that made a website editable. Increasingly, it's becoming the interface that makes large parts of the website invisible to the tools people now use to edit websites.

Our recent migration

We recently moved one of our largest clients' sites off of a CMS, ███████. It was a fairly large site: around 400 routes if you count locales.

The migration itself took some time (which is further evidence that piling all your content into a CMS causes headaches down the line). But it truly feels like a weight has been lifted now that it's done.

Now that content lives in the repo, the site is easier for non-engineers to change. That sounds backwards, but only because we've spent the last decade treating "non-engineer editable" and "CMS-backed" as interchangeable concepts.

In practice, our CMS made the site editable only within the shapes the CMS already understood. Changing a headline was easy; adding a new one was hard. Doing anything outside the content model turned back into an engineering task—except now the engineer wasn't just dropping in a JSX snippet, they were building a new block type, then a component to render it, then making sure the editor could actually interact with it.

After the migration, a lot of work got much dumber, in a good way: describe a change to a Cursor Agent, look at the preview URL, merge it. For trivial changes in a well-architected codebase, these don't even need code review. Someone can update the nav without logging into a separate product and hunting for the right place to click.

To be fair, the team we worked with was more technical and AI-native than the average client—we're not about to hand every client a full-fledged code-first repo and say "good luck." But I do think the number of people who can safely describe a change to an agent is much larger than the number of people who can safely write that change themselves. Probably also larger than the number of people who want to learn the peculiarities of whatever CMS setup an agency built for them six months ago.

The content model trap

The strongest argument against CMSs isn't cost, and it isn't vendor lock-in. Teams managing thousands of pages might feel those most acutely, but for simpler sites, I think the real tax is more subtle.

The following applies mostly to the common "page builder block" approach used in traditional CMSs: build a "page builder" block array, which takes in your predefined set of blocks and fields, and populate their content. I think another valid option, for non-collection content (more on that later), is to provide a simple click-to-edit interface that allows the user to edit the content of the page as a whole, and predefine that page's structure ahead of time. This allows for the initial set of content to be editable via a CMS, but for agents to move fast and not be blocked by a page builder for future edits. Then an issue of mixing content sources emerges, but that's a separate discussion.

The strongest argument is that CMSs turn website design into content-model design—the page stops being a page and becomes a set of allowed blocks and fields. This is fine in the early stages of a project, because the first content model maps cleanly onto the first version of the site: there's a hero, a logo marquee, and so on.

But when the company changes, the website has to change with it. And the content model your team built six months ago now needs to change as well; but rarely is it as flexible as it needs to be.

As a result, every new idea has to either fit within old abstractions or get built from scratch. If you need a new layout, add a block type. If you need a one-off section, decide whether to make it generic (which takes longer) or hack it in (which defeats the point of having a CMS at all).

This is how CMSes end up rigid while still marketing themselves as "flexible." The client can move blocks around—but only the blocks that already exist, and let's hope the padding and margin between the newly-moved sections is just right.

This may also read as a "self-report" of sorts — am I just admitting that my prior sites content models were too rigid? Maybe — but we've spent a lot of time trying to build flexible content models, and my point is that no content model can beat the flexibility of an agent that can simply construct brand new sections on the fly. Of course, the agent should not be running wild: a well-architected codebase with skills/rulesets, etc. is necessary to constrain the agent to a reasonable & non-sloppy degree.

Collection content is the exception

There are obvious exceptions, chiefly among them what I call "collection content": blogs, press coverage, case studies—anything that behaves like a collection and gets published on a real cadence. That's what CMSs are known for and best at. Predictable shape, many entries, appearing in a list. Great, use a CMS. (You could also solve collection content with Markdown w/ YAML frontmatter, which is what we often reach for nowadays.)

The common thread there is an actual publishing system. But a homepage or landing page is a very different animal from a blog post. Those aren't content objects so much as product surfaces—the text only really makes sense inside the design that presents it.

So collection content is the exception, not the rule. It's managed predictably, it appears in its own consistent format, and that's exactly why it's fine to live behind a content layer.

The default changes

I don't think CMSs are going away, and this isn't an argument for never using one. We still use them on a good number of client sites. I think the newfound prevalence and power of AI agents just means the default should change.

For a long time, the default was: start with a CMS unless you have a reason not to. Now I think the better default is: start with the repo unless you have a real publishing workflow. What we recommend to clients is to start with the repo, and add a CMS later if and when they actually need one.

Both approaches have tradeoffs. Starting with a CMS means inheriting a more rigid content model and eventually paying a redesign tax. Starting with the repo means learning a bit about Git (maybe), Cursor (or Claude Code, or any other agent), and PRs. (It used to mean learning an entire codebase—it no longer does.) For most marketing sites in an agent-prevalent world, we increasingly find ourselves advising clients to take on the second set of challenges instead of the first.