Why Independent News Publishers Are Losing Control of Their Own Content

Independent journalism is having a moment.

Newsletter platforms, self-publishing tools, and direct reader relationships have made it more viable than ever to build an audience without the backing of a large media organisation. Publishers who would have struggled to exist ten years ago are finding sustainable models built on reader trust and direct revenue.

But underneath that independence, a different kind of dependency has quietly accumulated.

The newsletter lives on Substack. The website runs on WordPress.com. The reader analytics come from a third-party platform. The subscriber list sits in Mailchimp. The comments are managed by Disqus.

Every one of those decisions was reasonable when it was made. Together, they mean that a publisher who considers themselves independent is actually dependent on five companies for the infrastructure that makes their work possible — and owns very little of what they’ve built.

What publishers think they own

When an independent publisher builds an audience, it feels like something they own. The readers chose them. The articles are their work. The brand is theirs.

But the infrastructure that connects them to that audience — the CMS, the newsletter platform, the analytics, the subscriber database — belongs to someone else. And the terms under which they can access it, change it, or take it elsewhere are set by vendors whose interests are not the same as theirs.

This becomes visible at specific moments:

When a platform changes its algorithm and organic reach drops overnight. When a newsletter platform changes its revenue share terms. When a CMS hosted on someone else’s servers goes down during a breaking news story. When a publisher wants to move their subscriber list and discovers that the export format makes migration practically impossible.

None of these are hypothetical. All of them have happened to independent publishers who believed their independence was more complete than it was.

The content management problem

Most independent publishers run their websites on hosted platforms — WordPress.com, Squarespace, Ghost Pro, or similar. These platforms handle the infrastructure, which removes a genuine operational burden. They also impose constraints that become more significant as a publication grows.

Plugin and extension limitations. Storage caps. Bandwidth throttling on lower tiers. Design constraints that make it difficult to create the reader experience the publication actually needs. And always — the content and data living on infrastructure the publisher doesn’t control, subject to terms that can change.

A publication that grows from a side project to a serious operation often finds that the platform that worked at the beginning has become the thing holding it back.

The reader data problem

This is the issue that gets least attention and carries the most risk.

Every reader who visits a publication, subscribes to a newsletter, or creates an account leaves data. Reading habits, subscription history, email engagement, location data. For EU-based publishers — or publishers with EU readers — this data is subject to GDPR.

When that data sits inside a third-party platform, the publisher is responsible for it under GDPR but doesn’t fully control it. They cannot always verify how it’s stored, who can access it, or whether deletion requests are fully executed across all systems.

For a publication built on reader trust — which is the foundation of every successful independent publisher — having uncertain answers to basic questions about reader data is a problem that compounds over time.

What genuine publishing independence looks like

A publisher that owns its infrastructure controls the full stack of its operation.

The CMS runs on servers the publication controls. Reader data is stored in a database under the publication’s jurisdiction, with access limited to authorised staff. The newsletter system is self-hosted, meaning the subscriber list is an asset the publication owns — not a dependency on a platform that could change its terms or shut down.

This setup requires more technical involvement than a hosted platform. But it produces something that a hosted platform fundamentally cannot: a publication that is genuinely independent — not just editorially, but operationally.

The content management system I built for my own publishing work — and that now runs content operations for larger clients — started from exactly this premise. A CMS that runs where you put it, stores data where you decide, and doesn’t require a vendor’s permission to modify, extend, or migrate.

That’s what publishing infrastructure built for independence looks like.

The question worth sitting with

If the platform you publish on changed its terms tomorrow — raised its prices significantly, restricted a feature you depend on, or simply shut down — what would your options be?

How long would it take to move your content? Could you take your subscriber list with you in a usable format? Would your reader data remain intact and compliant through the transition?

For a publication built on a direct relationship with its readers, these questions are worth answering before they become urgent.

If you’re running an independent publication and want to think through what genuinely owned infrastructure might look like for your operation, I’m happy to have that conversation.

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