Most publishers run newsletters on improvised tools that were never meant to be permanent. The gap between their CMS and their ESP is where the real problem lives.
Every publisher we talk to has built some version of the same workaround. And none of them planned to.
The pattern goes like this. A newsroom runs on a modern CMS. They produce content in their editorial tools, plan editions, manage their calendar across sections and beats. The CMS does what it was designed to do, and it does it well.
Then someone needs to send a newsletter.
Most content management systems were built to publish to the web. They were not built to produce email. So the team improvises.
Some install a separate tool alongside their CMS, a WordPress instance with a newsletter plugin, a drag-and-drop builder that can export HTML. Some set up RSS-to-email feeds that auto-generate editions from a content tag. Some just copy and paste: pull the text from the CMS, drop it into the ESP's template editor, fix the formatting, re-upload the images, and hope nothing breaks. Some have a developer who built a custom script that bridges the two systems, and who is now the only person who understands how it works.
The tools vary. The shape does not. A CMS that holds the content. A bridge layer that reformats it for email. An ESP that sends it. And a team that holds the whole thing together manually.
The scale of what newsletters actually require
The publishers who have figured out newsletters did not do it with workarounds. They did it with dedicated infrastructure and serious investment.
The Washington Post built Carta, an entire in-house newsletter platform, supported by a team of more than ten engineers. The New York Times has 16 million newsletter subscribers and runs roughly 100 newsletters. Axios scaled its entire business model on daily newsletter editions. Politico and the Financial Times each run dozens.
These are not publishers who found a clever plugin. These are organizations that recognized newsletters as core infrastructure and built accordingly. The results speak for themselves: loyal newsletter readers are multiple times more likely to subscribe and stay than readers acquired through search or social.
But most publishers are not the Washington Post. They do not have ten engineers to dedicate to a newsletter platform. They have an editorial team, a CMS, an ESP, and a gap in between that somebody filled with whatever was available.
What the workaround actually costs
The obvious cost is time. Every edition means moving content from one system into another, reformatting it, checking that images render, verifying links, previewing on mobile, and hoping the export does not introduce something the ESP will reject. Editors spend 30 to 90 minutes per edition on work that is purely mechanical, not editorial.
But the deeper cost is structural. When newsletter production lives in a different system than content planning, nothing is connected.
An article updated in the CMS after being copied into the newsletter stays outdated in the email. A story pulled from the edition plan still appears in the newsletter draft. The editorial planning layer and the newsletter production layer are not just separate tools, they are separate realities.
Breaking news cannot flow directly into email without manual intervention. The editor has to leave the CMS, open the bridge tool, find the right template, paste the content, preview it, and send. The 90-second window for a breaking alert becomes a 15-minute scramble across tabs.
Design consistency is a negotiation, not a guarantee. Every newsletter is rebuilt from scratch or from a template that drifts over time. Fonts, spacing, image sizing, ad placements, all managed by hand, all subject to human error, all invisible until a reader sees something broken in their inbox.
Scaling means hiring. Adding a new newsletter means training someone on the bridge workflow, building a new template, setting up a new sending list, and hoping the documentation from the last setup is still accurate.
Analytics are fragmented. ESP data lives in one place. Web traffic from newsletter clicks lives in another. Editorial planning data lives in a third. Nobody has a unified view of which editions perform, which stories drive engagement, and which newsletters justify the time they consume.
One publisher we worked with had over 50,000 lines of custom code holding their newsletter system together. Two full-time developers maintained it. The editorial team described the publishing process as demotivating.
Why this matters right now
Three things are converging that make the duct-tape layer more expensive than it has ever been.
First, direct channels are becoming essential. Facebook referral traffic to news sites has dropped roughly 80% from its peak. Google's AI Overviews are reducing click-throughs to publisher sites. The platforms that once delivered audiences for free are pulling back. Email is the most reliable direct channel that exists. It does not depend on an algorithm. It does not disappear when a platform changes its feed. But you cannot scale a direct channel on manual production.
Second, newsletters are no longer a growth experiment, they are a retention engine. The data is consistent across every publisher that has measured it: newsletter subscribers convert to paid at higher rates, retain longer, and engage more deeply than readers acquired through any other channel. Publishers who treat newsletters as a side project are leaving their strongest retention lever underbuilt.
Third, the talent risk is real. The same forces that pulled journalists to Substack are accelerating. Mehdi Hasan built 50,000 paying subscribers after leaving MSNBC. Oliver Darcy turned an independent newsletter into a profitable business within months of leaving CNN. Jim Acosta quickly built an audience of over 280,000 subscribers. Publishers who do not give their best writers a fast, frictionless way to reach readers directly are leaving those people one frustrating week away from building their own.
The duct-tape layer does not just cost time. It caps what newsletters can become. And the cost of that cap is growing every quarter.
The missing layer
The gap is not the CMS's to fill. A modern CMS serves publishers, broadcasters, and enterprises. Its roadmap reflects that breadth. Building a dedicated newsletter production environment would mean building a product within a product. That is not where CMS focus should be, and most CMS teams know it.
The gap is between systems. The CMS handles content and planning. The ESP handles delivery. What is missing is the production layer in between, the place where an edition is assembled, validated, previewed, and scheduled without leaving the editorial flow.
The publishers who have solved this at scale share a common architecture: CMS for curation, a dedicated production layer in the middle, and an ESP for delivery. When those three layers are connected, launching a new newsletter takes hours instead of months. Production per edition drops from 45 minutes to under two minutes. Whether you run three newsletters or thirty, the production model is the same.
The fact that publishers independently built the same category of workaround, without coordinating, without a shared playbook, tells you the need is structural, not situational. They arrived at duct-tape solutions because nothing else existed in the space between their CMS and their ESP.
That space is where newsletters are actually made. And it does not have to be held together with improvised tools and institutional memory.
Embrin is a newsletter production platform that connects your CMS to your ESP. Your editorial team shapes each edition and sends it to the right audience in about 90 seconds. No custom code. No production bottleneck. No reason your next newsletter should take longer to produce than it does to write. See it with your own content.