The Tech Powering the Morning Brew Machine
An ecosystem of custom-built software that zigs where legacy media zags.
Last week, Morning Brew sent 16 newsletters to more than 2.5 million people around the world. When we weren’t doing that, we released two podcast episodes interviewing some of the biggest names in the business world.
How does a small team with limited experience in the media industry manage to pull that off?
First, it requires a hyper-efficient content creation process, from writing to editing to fact checking. But equally as important is the intricate, bespoke tech ecosystem we’ve built to support our content creation process. In this post, I’ll walk you through our journey from midnight HTML coding to streamlined automations.
Just three years ago Brew writer (now Managing Editor) Neal Freyman would spend nine hours a day writing stories for our daily newsletter, then spend the next few hours copy and pasting those stories into a hard-coded HTML file. Assuming he didn’t accidentally delete a parenthesis or leave a stray quotation mark anywhere (which led to a ton of debugging), we as a team would start copying over each story into Wordpress to publish to the Brew website by about 9pm.
By then, CEO Alex Lieberman would ideally have the final copy for the next day’s advertisement ready. We’d move the email template over to Mailchimp, send a few test emails to make sure everything looked good (it often didn’t), and finalize the newsletter right around 10pm. Between then and 6am the following morning, we’d pray our site wouldn’t crash, considering we needed Mailchimp to scrape our RSS feed and pull the content to send to our readers…all 100,000 of them.
Fast forward to today. If we had to, Morning Brew could launch an entirely new content vertical in under 15 minutes — fully supported with a custom email template, webpages, referral program, advertising network, content management system (CMS), and everything in between.
By the time a Brew writer logs into the CMS to prepare the newsletter, the ad is already waiting, having been approved by our advertising partner days ago. With just a few clicks the stories are published across our website and pushed to Google and Apple News. A few more clicks and a perfectly templated HTML email is generated and ready for send. Rinse wash repeat for our 16 weekly newsletters and biweekly podcast episodes.
About a year ago I outlined how Morning Brew’s hugely successful referral program works in great detail (you can read it here). To this day, people continue to share it on LinkedIn/Twitter and write in to tell me how much it’s helped them.
The experience has taught me two things:
- People appreciate transparency. In a world of hyper-competition, closely guarded IP, and often-shady business practices…it can be a breath of fresh air to see behind the curtains of some of your favorite companies without the polished press release.
- Our problems and solutions aren’t unique to us. A referral program for a newsletter-first media company focused on business news is incredibly specific. However, the technology, strategy, and psychology we used can be deployed across a broad spectrum of industries.
Which led me to writing this piece.
As the person in charge of our product and tech, of course I want to showcase all of the cool things we’ve built. But I also think it’s worth going a layer deeper. In an industry full of incumbents built on legacy technology, we’ve had the opportunity to take this decades-old medium — email — and build an intricate tech-forward ecosystem to supplement everything we do.
Sure, it’s far from rocket science, and we don’t have AI writing the newsletters (yet). But there’s a lot that goes on behind the scenes to make sure that newsletter hits your inbox every morning at 6am.
Comet: Custom Built AdOps & Sales Tool
Comet is responsible for everything that takes place between:
Point A — Company X signs a deal to advertise in our newsletter/website/podcast
Point B—those ad placements go live in our newsletter/website/podcast
Previously, our entire sales and adOps process lived in email threads that grew to be 40+ emails long. We’d Cc the design team when artwork was needed, FWD to the creative team when it was time for copy edits, then loop in the account manager to coordinate sending tests to the partner for final approval.
Now take that and multiply it by 3 ads per newsletter, 4 newsletters, 1 podcast, and branded content on the website.
Then we introduced Comet…
Comet tracks the progress of every upcoming (and historical) ad placement and streamlines the entire process from inception to completion. Placements are easily accessible and categorized by date, newsletter, company, type, etc.
When our sales team signs a deal with Company X for 5 placements, those placements are added to Comet, where an account manager, copywriter, and reviewer are assigned to each individual placement.
Three weeks prior to the go-live date of an individual placement, the partner receives an automated email asking them to submit assets. If they don’t, they’ll get a reminder a few days later. Followed by another, each more urgent than the last. After three requests, an alert is sent to someone on our team to reach out.
When the partner goes to submit their assets, the page on Comet clearly communicates all the requirements and lays out the options for A/B testing. Everything that used to be copy and pasted into countless email threads is replicated in Comet in a streamlined manner. Comet also stores information about existing clients, which allows us to auto-populate repetitive fields and reduce the workload of our partners.
Once we receive the assets, the copywriter assigned to the placement is notified via Slack (Comet has a custom integration built into our team’s Slack channel). Then they begin writing the ad copy in a Google doc that was formed automatically upon the initial creation of the placement in Comet.
After the copywriter completes the ad copy using the assets the partner submitted, they’ll notify the reviewer to…review (all within Comet), and then send the first draft to the partner with a click of a button. The partner receives the ad copy in an embedded Google doc that allows them to make comments, request edits, or approve the copy.
Each placement is capped at a strict number of revisions, which is communicated clearly on each subsequent round of edits. Meanwhile, all this activity is being tracked in real-time on the placement’s home page on Comet. This allows everyone on the team to monitor the progress of each placement, access the assets, and monitor what actions have (or have not) been taken.
When the ad copy is approved, the team creates a mockup placement within Comet to send to the partner for final approval. The mockup is a nearly identical web-based imitation of how the placement will appear in our newsletter.
In the final step, the partner can request any last minute changes, or approve the mockup. Upon approval, we timestamp the partner’s sign-off and it is sent to OSLO via API.
OSLO: Custom Built CMS
Neal was a trooper (remember the introduction?)…but when it came time to hire writer #2, it would be tough to attract top talent when their day would mandate several hours of copy and pasting into a static HTML template.
OSLO has given the Brew’s editorial team a platform to write / edit / publish stories and craft beautiful email newsletters without the manual processes and technical know-how required in the past. Their job is to create engaging content; our job is to make the tech out of sight, out of mind.
Morning Brew currently has several newsletter verticals (Morning Brew Daily, Emerging Tech Brew, Retail Brew, Light Roast, and The Essentials). Within each vertical, writers can create a new newsletter issue, add all the email specific fields (subject line, preview text, introduction, etc.), and then begin building the newsletter by adding individual stories.
Each story is created exactly how you’d imagine any CMS working. We built a robust media library to manage our inventory of images and gifs. Each asset contains the proper source attribution and alt tags needed for the newsletter. We also have a live preview mode that applies our custom styles so the editorial team can view the story exactly how it would appear within the final newsletter.
Once individual stories are published, they’re sent via API to our core website for visitors to read, and are also pushed to both Google and Apple News aggregators. Social share links are generated automatically upon publishing, allowing readers to share each story on Facebook, Twitter, LinkedIn, and email. Each subsequent edit in the story will be automatically updated and reflected across all platforms.
Ultimately, each newsletter issue consists of several of these news stories, ads, and “other” stories (content that solely lives in the newsletter and not as a website article, i.e. the short “What Else is Brewing” section). Each one of these stories can be reordered via drag-and-drop on the newsletter issue page so the editorial team can make adjustments to the newsletter order on the fly.
Each story, regardless of type, can be A/B tested (meaning half of the audience will receive one version of the story, and the other half will receive a different version). This gives us the flexibility to do a couple of things:
- Provide testing capabilities to our advertising partners (we can test different images/gifs, headlines, CTAs, and other variables)
- Internally test different language (when incentivizing readers to click on a link promoting one of our own products, we can learn whether one version of language is more effective than another)
- Increase our inventory (rather than promoting 1 thing to the entire list, we can promote 2 things to half our list)
It’s not uncommon on any given day for us to have multiple ads, stories, and other sections being split tested in real-time. OSLO is built with these capabilities, fully integrated with our ESP, and allows our content team to set up these tests without having to worry about any sort of conditional logic coding.
The content team can publish the entire issue to our website / archive with a click of a button, which also creates the final product — a perfectly coded HTML template, responsive on all device types, and built for every email client ranging from Gmail to Outlook 2003.
To recap, the email you get every morning contains stories that are shareable across multiple networks, and content blocks that are customized and entirely unique to you. Working behind the scenes, OSLO allows the content team to focus on writing, the sales team on selling, and our growth team on testing and optimizing.
Core Website: Consumer Facing Site
For lack of a better name, the core website is morningbrew.com. It’s where end users go to subscribe to our newsletters, read our content, and refer other readers.
Not long ago it was actually a collection of websites. Our rails application handled new users and subscriptions, but all of our stories were hosted on a WordPress site and our newsletter archive was hosted on a second WordPress site…all disguised under a single domain. If that’s confusing, it should be — and it wasn’t fun to manage either.
According to W3techs, WordPress has 61.8% of the CMS market share and powers 35% of the internet. If you wanted to publish content online, it is one of the easiest platforms to do so. That being said, I personally find it limiting, archaic, and frustrating to use.
Last year we made the decision to host all of our content on our custom-built rails site.
This was by far one of the best decisions we’ve made to date. With all our content living in a custom-built solution, we had the flexibility to build any feature, integration, or add-on with just a few additional lines of code.
If you visit our site directly from the newsletter, we know which newsletters you’re subscribed to and what content you like to engage with. This leads to a far superior experience on our site. We can tweak the recommended stories algorithm to better serve the end user and keep them on site longer, engaging with content that is relevant and interesting to them.
In addition to improving the user experience, custom-built solutions lead to improved efficiency via custom-built integrations. As referenced in the previous sections — the core website is fully integrated with OSLO and Comet. For example:
- When we hire a new writer and they create an account in OSLO, they’ll have a dedicated contributor page on the core website displaying their work
- When a daily newsletter issue is published in OSLO, the core site knows to hide that issue until 5am ET the following day
- When Company X wants to sponsor all stories related to AI on the site, with a few clicks in Comet our inventory of AI stories now has Company X’s logo and ad displayed on the webpages
These are just a few examples showcasing how the three custom-built solutions are all interconnected and optimized for our use cases.
When our use cases change, our platform does too. Relying on legacy solutions may limit our ability to innovate, and depending on 3rd party software means our roadmap is dependent on theirs (i.e. if we want to accomplish something their software doesn’t offer, we’re waiting for them to have to build it…if they choose to build it).
Last, our referral program, responsible for well over 1 million subscribers, is a custom built solution and an integral part of our core website (you can read more about it here).
From browsing content as a new visitor to subscribing to a newsletter and then referring others to that newsletter…our website is built from the ground up with growth and UX top of mind.
I brushed over a lot. Comet has similar processes for podcast placements and an API integration with our core website that allows us to toggle on branded content and editorial sponsorships. OSLO has the ability to publish web content outside of the newsletter domain, feature specific stories, create customized “share sections,” and much more.
What is important to note is these solutions can be entirely customized to our team’s exact needs as we continue to scale our product offerings. While that’s not always possible, I couldn’t be more in favor of building custom in-house solutions vs leveraging 3rd parties.
Relying on 3rd party software is limiting — you are one of many customers, whose wants and needs could vary drastically from others. It’s also an additional expense. At almost every opportunity, we have at the very least evaluated what it would look like to build an in-house solution.
It’s that mindset that has led us to build a unique tech ecosystem comprising our core website, OSLO, and Comet, all of which are catered exactly to our needs. I believe it’s a competitive advantage, and one of the many reasons Morning Brew has found success.
**The largest possible shoutout to the two very talented engineers I work beside every day — Benjamin Hargett and Everest Guerra. This blog is truly just the tip of the iceberg when it comes to all of the different projects and initiatives we’re working on, and I bet up until this point you would have guessed we have a lot more than 3 total engineers on our team. It’s a testament to their talent, intelligence, and hard work.
***Let’s continue the conversation on twitter. Follow me @denk_tweets.