We talked ourselves out of the CMS

Josh and I have been building WordPress sites for enterprise SaaS companies for the better part of a decade. We got on a call that was supposed to be about a CSS cleanup, and it turned into whether we still need the CMS at all. This is roughly where it went. I'm writing it down because the conversation is what led to the accountable workflow we published next to this one, and because I think a lot of shops are about to have the same one.

The bargain we made with the CMS

Here's the thing we kept circling. The whole reason we moved clients to a CMS years ago was editing tools. That was the pitch. WordPress gave a client a login and a way to change their own pages without calling us. Every few years the tools got reworked, ACF fields, then Gutenberg blocks, and we kept taking the new thing because that's where WordPress was pushing. We got good at building editable block systems.

The user who never showed up

Then Josh said the quiet part. Across the whole arc of it, the self-serve promise mostly didn't land. Not because the tools were bad. Because at every enterprise company we've worked with, the person who actually builds and rearranges product pages is either a web marketing manager who already knows HTML, or it's us. I've watched this for years. A non-technical marketer does not log into WordPress and rebuild a product page with components and accordions. They never have. So we were breaking our backs building editing tools for someone who wasn't going to use them.

And it isn't a WordPress problem. Webflow is the same, so is every other CMS. Same limitation, different login. It's all in how you wield it. No product marketer is building sophisticated pages in any of them.

The agent moves the line

What changed is the threshold. Those editing tools existed to let someone skip the code. An agent skips the code for you now. It writes the markup, the logic, the database query, the animation. You have to know what you want the page to be, and be able to judge the result. That's a real skill, but it isn't front-end engineering. Once the agent does the building, an editing UI for non-technical users is solving a problem that mostly isn't there anymore.

We've both watched pages get built lately as plain code. No blocks, no CMS behind them, just files in a repo. And nobody blinked. Stakeholders looked at them, approved them, moved on. That told me something. The appetite we kept tiptoeing around is already here.

What they actually wanted was speed

So if it isn't editing access, what is the marketing team actually asking for? We kept landing on one answer. Speed. The friction was never that a PMM couldn't log in and edit. The friction is that a request goes in and then sits. It waits on the dev queue for five days, ten days, gets lost under other work. If you're the person who wanted an event promoted on the homepage, you don't want a login. You want it live.

Self-serve was a bad answer to a real problem. The real problem is turnaround. Give someone a clumsy promo module in theme settings and tell them to fumble through it themselves, and you haven't fixed the thing that actually bothered them.

So who picks up the ticket?

Which is the exact moment the conversation turned into a plan.

That's the accountable workflow. The request stays where the team already works, an agent picks it up, opens a PR, posts back that it's ready, a developer approves, it ships. Even with a person approving every PR, 24 hours beats five days. We wrote that idea up on its own.

Embrace and extend

None of this means torching WordPress. My actual proposal is smaller and more boring than that, and I think that's why I like it. Embrace the WordPress we already have. Extend it. Stand up an Astro site next to it and build the pages there. Keep the things a CMS is genuinely good at, blog posts, news, events, customer stories, in WordPress. Move it to the back of the house, lock it down, and pull it through a REST API. The front of the site becomes code. The database stays for the stuff that's actually dynamic.

The reason to do it isn't just today's pages. It's the next six, nine, twelve months. Something new shows up on the frontier and someone wants it on the site. If we're fighting to cram it into a block, we lose. If the site is code, we just build it.

Code is what lets the agent keep the house clean

There's a quieter reason to prefer code over a database, and it's the one that sold me. When everything is in the repo and in context, the agent can clean up after itself. It replaces a page and then goes, let me check whether that old component is used anywhere else, and remove what isn't. You can watch it reason through exactly that. A CMS hides half of it behind the database, so the agent can't see it, and the cruft just piles up.

The catch is that the agent builds by matching what it sees. Point it at a clean, consistent codebase and it follows the pattern. Point it at a hodgepodge of templating and style systems and it doesn't know what to do. So the work is less about hand-coding and more about steering: keep the repo coherent, scope the styles to the page, and set the direction the agent builds toward.

For that direction, we don't think most teams want a full componentized design system with a Storybook. We think a lot of them want a design.md file and a few references. Brand colors, spacing, the components worth reusing, a short list of don'ts. Enough to keep it on brand, without the overhead.

# design.md

Brand
  accent   #b80c09   fills only, never body text
  ink      #040f16   page background
  text     #eef2f6   body   ·   muted #8a9aa4

Type
  display  Figtree 600
  body     Figtree 300-500

Rules
  · scope every page's styles to that page
  · reuse the components in /components before adding new ones
  · no decorative eyebrows

Where we landed

We didn't settle everything on that call. Josh is more careful than I am about performance and about not leaving a mess in the codebase, and he's right to be. But we both walked away in the same place. For marquee marketing pages, the CMS was solving a problem we don't really have, and creating a few we do. The tools were built for a user who never showed up. What the marketing team actually wants is speed, and there's now a clean way to give it to them.

This is the kind of thing we're working through with the enterprise SaaS teams we build for here in the Bay Area. If you've got a marquee site and you're wondering whether you still need the CMS behind it, that's a good conversation to have. Reach out. We're here for you.