Madalin
Development enhanced by AI

The Hidden Cost of WordPress.com and Substack for Serious Publishers

WordPress.com and Substack look affordable when you start. As your publication grows, the real costs — in money, control, and dependency — become harder to ignore.

A publisher at a desk reviews two large invoices side by 
side — one labeled with a newsletter icon, one with a blog 
icon — both showing growing numbers. A small self-hosted 
server sits quietly on a shelf behind them, glowing green, 
with a price tag showing a fraction of the invoice totals. 
The publisher looks thoughtful. Flat 2D editorial 
illustration, warm neutral tones with amber accent on the 
invoices and teal on the server, no text in the image.

Every serious publication starts somewhere modest.

A WordPress.com site because it was quick to set up. A Substack newsletter because the barrier to entry was effectively zero. Both decisions made sense at the time — low cost, low friction, immediate results.

The problem isn’t where you start. It’s what you discover when you try to grow past it.


The WordPress.com cost curve

WordPress.com’s pricing looks straightforward until you need to do something specific.

The entry tiers are genuinely inexpensive. But as a publication grows — in traffic, in content volume, in the specificity of what it needs — the limitations of lower tiers become friction points. Custom plugins require a higher plan. Removing WordPress.com branding requires a higher plan. Adequate storage, proper analytics, the ability to install the tools your editorial workflow actually needs — each one pushes you toward the next tier.

The top-tier plans are not cheap. And at that price point, you are paying a significant annual fee to run your publication on infrastructure you don’t own, with constraints you didn’t negotiate, subject to terms that can change.

There is also the question of what you’re building. Every article, every reader relationship, every piece of SEO authority you accumulate on WordPress.com is built on someone else’s platform. Moving it is possible — but it is never as clean as the migration guides suggest.


The Substack model and what it actually costs

Substack’s model is straightforward and, on the surface, attractive: free to start, with a revenue share on paid subscriptions.

For a publication with no paying subscribers, the cost is genuinely zero. For a publication building meaningful paid subscription revenue, the cost becomes significant quickly.

At ten percent of revenue, a publication generating five thousand euros per month in subscriptions is paying five hundred euros per month to Substack — six thousand euros per year — for infrastructure that costs a fraction of that to run independently.

That’s the straightforward financial calculation. The less visible costs compound it.

Your subscriber list is inside Substack’s platform. You can export it — Substack does allow this — but your readers’ experience, their subscription management, their payment details, all of it runs through Substack’s infrastructure. If Substack changes its terms, introduces features that conflict with your editorial values, or simply becomes a platform you no longer want to be associated with, leaving is disruptive in ways that affect your readers directly.

Discovery dependency. Substack’s recommendation engine drives meaningful traffic for many publications. That’s a genuine benefit — and a dependency. Publications that have grown significantly on Substack recommendations have built their audience partly on a distribution mechanism they don’t control.

GDPR exposure. For EU-based publishers or those with EU subscribers, reader data sitting inside a US-based platform raises questions that are worth asking clearly. Where is subscriber data stored? Under what jurisdiction? What are your obligations as a data controller when the processor is Substack?


What serious publishers actually need

A publication that has grown past the hobbyist stage has specific requirements that generic platforms handle awkwardly at best.

Full control over the reader experience. The design, the navigation, the subscription flow, the way content is presented — these should reflect editorial decisions, not platform constraints.

A subscriber list that belongs to you. Not just exportable in theory, but genuinely owned — stored in your own infrastructure, under your control, with access and deletion manageable independently of any platform.

Content that lives where you put it. Years of archive, SEO authority, reader engagement data — on infrastructure you own, not infrastructure you rent.

Predictable costs. Not a percentage of revenue that scales against you as you grow, and not a tier structure where the next capability you need always requires the next plan up.


What self-hosted publishing looks like

The technical barrier to self-hosted publishing is lower than most people assume. What it requires is not deep technical expertise — it requires a CMS that runs on infrastructure you control, a newsletter system that manages your subscriber list independently, and someone who can set it up and maintain it properly.

The result is a publication that runs on a fixed, predictable infrastructure cost — typically a fraction of what a growing Substack publication pays in revenue share — with no platform constraints, no dependency on a third party’s decisions, and reader data that stays exactly where you put it.

For a publication built on a direct relationship with its readers, that ownership is not a technical detail. It’s the foundation everything else is built on.


The question worth asking

If your publication is generating meaningful revenue or meaningful traffic, one calculation is worth doing clearly: what are you actually paying your platform — in fees, in revenue share, in the constraints you work around — and what would it cost to own that infrastructure instead?

For most serious publishers who do that calculation honestly, the answer is clarifying.


If you’re at the point where that conversation feels relevant, I’m happy to work through what independent publishing infrastructure might look like for your specific situation.

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

Madalin

Madalin

AI integrator

🚀 Senior Architect | SRE & Database Expert | AI Orchestrator 👋 Building the future at the speed of thought. ⚡️ I don't just write code; I architect high-performance, bulletproof ecosystems. With a foundation in Systems Engineering and a mastery of Go and TypeScript, I bridge the gap between heavy-duty backend reliability and seamless, high-conversion frontends.

Continue the conversation

If this article reflects the challenges your organisation is navigating, explore more practical guidance across Madalin.