What a News Publication Actually Needs From Its CMS

Most publications don’t choose their CMS. They inherit it.

A previous developer recommended WordPress because they knew it. A founder picked Ghost because someone wrote a blog post about it. A platform was chosen in a hurry because launch was approaching and a decision needed to be made.

Years later, the editorial team works around the things it can’t do. The developers maintain a system built for something slightly different from what the publication actually needs. And any conversation about changing it runs into the accumulated weight of content, configuration, and workflow that has built up inside it.

This is how most publications end up with a CMS that mostly works — and consistently fails at the specific things that matter most.

What a CMS is actually for

A content management system has one job: to make it as easy as possible for editorial teams to produce, manage, and publish content — without technical friction getting in the way of editorial work.

That sounds simple. It’s surprisingly rare.

Most CMS platforms are built around a generic model of content: a title, a body, some metadata. That model works for a personal blog. It works less well for a publication with multiple content types, complex editorial workflows, contributor management, versioning requirements, and an audience relationship that goes beyond pageviews.

The friction appears in small ways first. A field that doesn’t quite match the content type. A publishing flow that requires a workaround. A search function that doesn’t surface what editors need. Over time, these small frictions compound into a system that the editorial team tolerates rather than relies on.

What serious editorial workflows actually require

Content modelling that reflects editorial reality. A news publication doesn’t just publish articles. It publishes breaking news with different urgency than features. It publishes investigations with different structure than opinion pieces. It publishes newsletters that are related to but distinct from website content. A CMS that treats all of these as variations of the same object forces editorial work into a shape it doesn’t naturally take.

Contributor and role management. Publications work with staff writers, freelance contributors, editors, subeditors, and fact-checkers — each with different levels of access, different points in the workflow, and different relationships to the content they touch. A CMS with two or three access levels — administrator, editor, author — handles this crudely at best.

Versioning and editorial history. Who changed what, when, and from what previous state is not a nice-to-have for a publication. It is operationally essential. The ability to recover a previous version, compare drafts, and understand the editorial history of a piece protects the publication’s integrity and the editor’s sanity.

Media management that doesn’t fight you. Images, audio, video, documents — managed in a way that makes them findable, reusable, and properly attributed. Not a flat upload folder with filenames that made sense to someone three years ago.

Performance under publishing pressure. A CMS needs to be fast when it matters most — which is precisely when news is breaking and traffic is unpredictable. A hosted platform that slows down under load at the moment a story is going viral is not a tool. It is a liability.

The self-hosted advantage for publishers

A self-hosted CMS — running on infrastructure the publication controls — offers something that no hosted platform can: the ability to build exactly what the editorial workflow requires, without negotiating with a platform’s constraints or waiting for a vendor’s roadmap.

Content models can be defined around how the publication actually works. Workflows can match editorial process rather than forcing editorial process to match the software. Integrations can be built to the publication’s specific requirements — not to the limited set a platform supports.

And critically: the content, the reader data, and the editorial history all live where the publication puts them. Not in a vendor’s database, subject to their retention policies and their definition of what a backup means.

The CMS I built for my own publishing work started from exactly these requirements. Editorial simplicity on the surface — writers and editors working without technical friction — with the flexibility underneath to model content properly, manage contributors, and integrate with the tools a publication actually needs. Running on infrastructure the publisher owns, with no platform in between making decisions about what’s possible.

The right question to ask about your CMS

Most editorial teams have a list of things their CMS can’t do — or does badly — that they’ve stopped mentioning because nothing changed when they mentioned it before.

That list is worth revisiting. Not as a wishlist, but as an honest assessment: are these limitations the cost of using any CMS, or are they the cost of using this particular one?

For publications where the answer to that question is consistently the second — where the friction is specific to the platform rather than inherent to the work — a different approach is worth understanding.

If you’re running a publication and want to think through what a CMS built around your actual editorial workflow might look like, I’m happy to have that conversation.

Connect on LinkedIn or reach out directly at hi@madalin.me.