Architecture, not content

The same conversation keeps coming up. A marketing lead describes their website, and at some point they say: "We need to involve the agency for every small change."

It's easy to hear that as a complaint about the CMS. Or about the agency. But I've started hearing it differently. It's an architecture problem.

The promise that inverted

WordPress started as a tool for writers. Somewhere along the way, it became a tool that requires a developer to maintain.

Security updates that break things. Plugin conflicts that need debugging. Template constraints that turn a simple text change into a support ticket.

The people who were supposed to be the users became dependent on specialists.

I talked to a marketing team recently that needed to update a single line of text on their homepage. It took two weeks. Not because anyone was slow, but because the change required a developer to modify a template, test it against the plugin stack, and push a new build. A one-sentence edit became a project with a timeline.

This isn't unique to WordPress. It's a pattern. Tools accumulate complexity over time. The original simplicity gets buried under layers of capability that serve the platform more than the people using it. Drupal went through the same arc. Joomla before that.

Architecture carries opinions

This rarely gets framed as an architecture decision. But that's what it is.

Every CMS carries assumptions about who does the work. Some architectures assume a developer sits between the editor and the published page. Others don't.

When the architecture assumes a developer, every change becomes a request. Every request becomes a ticket. Every ticket takes time. The team that wanted to move fast now moves at the speed of someone else's queue.

It's not that the team is slow. It's that the architecture decided who controls the publishing workflow. And that decision has consequences that compound over months and years.

Choosing differently

Most teams don't realize they made this choice. They chose a CMS based on features, or familiarity, or what the agency recommended. The workflow assumptions were already baked in.

A web project that takes six months is telling you something about the tools, not the problem. The question worth asking isn't which CMS is best. It's whether the architecture treats editors as users or as passengers.

The architecture is always making decisions about who gets to work independently. It's worth asking what yours decided.