We built Megargy Newsletter Service out of frustration with existing platforms. Sending a digest of Babylon’s latest articles should be straightforward: simple to set up, easy to adjust months later, and priced according to the number of emails sent rather than access to basic features. The opportunity to embrace AI-assisted development, using a language we had never written in before, gave us another reason to build it.
We chose the Megargy name to keep the newsletter service distinct from Babylon’s core business.
A simple requirement
At Babylon, we wanted readers to be able to subscribe to an email digest of our articles. We already publish those articles on our website, so there should be no need to assemble a separate newsletter each time.
This is what RSS-to-email does. A website’s RSS feed makes its latest articles available to other services. The newsletter service reads that feed and, on a chosen schedule, sends subscribers a digest of new articles.
Our requirements were modest: a presentable subscription form, a well-formatted email, control over when it was sent, and the ability to send from our own domain. Once configured, it should run without our involvement.
The frustration was how much unrelated functionality we had to navigate to configure those few things. We needed RSS-to-email, not an entire email-marketing operation.
Simple when you return, not just when you start
“Set up once and forget” is not just a requirement for automation. It is also a requirement for the user interface. Successful automation means we may not open the application for months. When we return to change something, we should not have to relearn the product.
With existing platforms, specifying a date format or finding the sending schedule took more effort than we expected. Custom-domain configuration was also complicated, and the settings we needed were surrounded by unrelated features.
We wanted a small number of settings that were easy to find and understand, sensible defaults, and custom-domain setup that explained what to do and made progress clear.
Charge for usage, not access to the essentials
RSS-to-email and sending from our own domain were basic requirements, not premium extras. We disagreed with having to move to a more expensive subscription to enable them. Our view is that fees should be driven by email volume rather than access to these capabilities.
A back-of-the-envelope estimate of the cost of running the service on AWS strengthened that view. For our requirements and sending volumes, the monthly charges we were seeing looked relatively high compared with the underlying infrastructure costs.
Infrastructure is not the whole cost of providing a service: development, maintenance and support all need to be paid for. Nevertheless, the calculation suggested there was room for a focused service with pricing more closely related to usage.
A practical project for AI-assisted development
We wanted to fully embrace AI-assisted development on a real project from start to end. A service we needed ourselves was a useful opportunity, and we chose Go, a language we had not written in before.
AI assisted throughout: analysing the problem, exploring design options, writing code and testing the implementation. It helped us work through possibilities more quickly, while we remained responsible for the final decisions and for satisfying ourselves that the service behaved correctly.
How hard could it be?
On paper, an RSS-to-email service sounds straightforward. Build a form to collect email addresses, read the website’s RSS feed, and use an AWS schedule to run once a week, looping through the subscriber list and sending the emails using Amazon SES.
Surely that could not take more than a couple of weeks, especially with AI writing much of the code?
It took much longer!
Building a service that behaves reliably, without somebody watching over it, is a different matter. Subscriptions need to be confirmed and unsubscribes honoured. Bounces and complaints need handling. A sending run that fails halfway through must not result in duplicate emails when it is retried. There are decisions about which articles count as new, what happens when a feed changes, and how schedules work across time zones.
Custom-domain setup needs to be secure as well as understandable.
A low estimated AWS bill was not the same thing as a small development project.
We came away with a newfound respect for the engineering behind the established services. That did not change our objections to charging extra for basic features or making ordinary settings difficult to find. Changing a date format or sending time should be straightforward.
Starting with our own newsletter
Megargy Newsletter Service grew out of a need at Babylon, and we are using it for our own newsletter first. If it continues to run smoothly and there is interest from others with similar needs, we will make it more widely available.
We also want to explore support for the Model Context Protocol (MCP), which would allow compatible AI tools to work with the service. Rather than navigate settings, somebody could simply ask to change the sending day or date format. That will be beautiful.