There's a pattern we see in almost every large publisher we talk to. At some point, someone on the engineering team built a custom newsletter system. It started simple. Pull some articles from the CMS, drop them into a template, connect to an email service, schedule the send.
Then it grew. Ad placements needed their own logic. Different newsletter types needed different templates. The email provider raised prices, but the system was built around their API, so switching would mean rewriting everything. Someone added tracking. Someone else added audience segmentation through a separate tool. A third person built a preview system so editors could see what the newsletter looked like before it went out.
A few years later, you have 50,000 lines of custom code, two developers whose entire job is keeping it alive, and an editorial team that dreads the publishing process.
We know this because we lived it.
The three tools that already exist
Here's what most publishers already have, or should have, sitting in their stack.
A CMS. For publishers on Arc XP, that means Composer for writing and editing, WebSked for planning, and Publications for organizing content into editions. Arc XP powers over 2,500 publisher websites globally and handles billions of pageviews a month. It's very good at what it does. Content creation, editorial workflow, multi-channel publishing.
An engagement platform. For publishers who've outgrown Mailchimp, that usually means Braze. Braze handles audience segmentation, multi-channel delivery, scheduled and triggered sends, and real-time analytics. It processes over 2 billion messages a day and maintains 99.99% uptime during peak periods. It's built for scale in a way that no email service provider can match.
And a gap in between.
Arc XP knows what your editors wrote and how they organized it. Braze knows who your subscribers are and how to reach them. But neither one knows how to turn a curated set of articles into a finished newsletter edition. That's the gap where the 50,000 lines of code live.
Why the gap exists
Arc XP Publications lets editors curate articles into sections, pitch stories to specific newsletter editions, and lock an edition when it's ready. That's excellent for editorial workflow. But Publications doesn't render email HTML. It doesn't handle ad insertion. It doesn't preview the newsletter across email clients. And it doesn't send anything.
Braze, on the other hand, can send newsletters to millions of subscribers using Liquid templating, segment audiences based on behavior and preferences, schedule sends down to the minute, and track everything. But Braze needs something to send. It needs pre-built content, structured data, rendered HTML. It's the engine, not the assembly line.
So publishers build the assembly line themselves. And that's where things go wrong.
What goes wrong with custom builds
The presentation Embrin's Lead Engineer Janko Tomsic gave at an Arc XP workshop described a pattern we've seen at multiple publishers. The previous newsletter system at one large fashion publication was a custom solution with over 50,000 lines of code. It required two full-time developers just to maintain, fix bugs, and support the platform. It was tightly coupled to a specific email service whose prices kept climbing. And the editorial team was, in Janko's words, "demotivated and annoyed" when publishing content.
When the team assessed the actual requirements, the findings were striking. Templates almost never changed between newsletter types. The majority of sends went out at the same time every day. And around 80% of the content was simply curated from articles already on the website.
In other words, the custom system had been engineered for flexibility it never needed. The real job was simpler than anyone admitted. Take the articles the editors picked, lay them out in a template, attach the ads, and hand it to Braze for delivery.
The three-layer stack
The solution is three layers, each doing what it does best.
Arc XP handles content curation. Editors use Publications to organize articles into newsletter editions. One publication per newsletter type. Sections map to content blocks. The intro article carries configuration and editorial copy. When the edition is locked, the content is ready.
Embrin handles production. It pulls the curated content from Arc XP, lays it out in the template, inserts ad placements, validates everything, and pre-renders the newsletter data to a storage layer. The output is a structured dataset of reusable building blocks that can be combined into multiple newsletter formats. This happens automatically, hours before the scheduled send, so the data is ready and waiting.
Braze handles delivery. It picks up the pre-rendered data, applies Liquid templating to render the final HTML, segments the audience, and sends. Braze also provides the tracking, scheduled sends, breaking news triggers, and the infrastructure to deliver at any scale.
The result at that publisher. 95% less code. No active maintenance required. New newsletter types can spin up in hours instead of months. And it supports pre-scheduled sends, instant breaking news alerts, and individual or group preview sends.
Why this matters more now than it did five years ago
Three things have changed in publishing that make this stack architecture urgent.
First, publishers need more newsletters, not fewer. Facebook referral traffic to publisher sites has dropped by roughly 80% since its peak. Google's AI Overviews are cutting into search click-throughs. Most publishers expect the decline to continue. The direct channel, email, is now the primary path to readers. The Washington Post runs over 70 newsletters. The Wall Street Journal runs 40+. Publishers are expanding their newsletter programs because they have to.
Second, developer resources in newsrooms are scarce. Most editorial and product teams are small, generalist groups where engineers wear multiple hats. Having two developers permanently assigned to newsletter infrastructure is a luxury most publishers can't afford and a misallocation of talent even when they can.
Third, the economics of newsletters have changed. Newsletter sponsorships generate $5,000 to $12,000 per placement for publishers with 500,000+ subscribers. Email marketing returns $44 for every $1 spent. Publisher subscription revenue continues to grow year over year. Newsletters aren't a side project anymore. They're a revenue engine. And revenue engines need reliable infrastructure, not 50,000 lines of custom code held together by two people who really need a vacation.
What the editors actually experience
This is the part that gets lost in architecture diagrams. When the stack works, editors don't think about the stack.
They curate articles in the CMS they already know. They write an intro, maybe add newsletter-only content or adjust ad placements in Embrin's workspace. They preview the edition on mobile and desktop to make sure it looks right. And they send it, or schedule it, or let it go out on the pre-set time.
The entire process takes minutes. Not hours. Not half a day. Not a meeting with the dev team to ask why the template broke in Outlook again.
And because Embrin becomes the system of record for every edition, there's a permanent archive. Every newsletter that was ever sent, versioned, preserved, and available as a hosted web page. No more wondering what went out last Tuesday.
The opposite of over-engineering
The instinct at most publishers is to build for every possible future use case. What if we need twelve different template types. What if we need real-time personalization per subscriber. What if we need to integrate with four different ESPs simultaneously.
In practice, the assessment almost always reveals the same thing. Templates rarely change. Most sends are scheduled. Most content comes from the CMS. The complexity was aspirational, not operational.
The connected stack works because it respects this reality. Arc XP does what a CMS should do. Embrin does the narrow, specific job of turning curated content into a finished newsletter. Braze does what an engagement platform should do. Each layer is replaceable, upgradeable, and independently maintainable. None of them require 50,000 lines of custom code.
And nobody on your editorial team needs to feel "demotivated and annoyed" when it's time to publish.
Embrin connects Arc XP and Braze into a single newsletter workflow. Your editors curate in the CMS, shape the edition in Embrin, and send it to the right audience, all in about 90 seconds. See it with your own content.