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 configure and refine later, and sensibly priced. That is not what we found with incumbent vendors. Also, we had been looking for a small project in which we could make full use of AI-assisted development,1 inspired by the work of Wes McKinney.
We chose Megargy as a separate brand to distinguish the newsletter service from our work at Babylon.
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, the frustration came when we returned after the initial setup to tinker with or refine the newsletter: fields for basic parameters such as the date format and sending schedule were really difficult to find.
We wanted a small number of settings that were easy to find and understand, and sensible defaults. Custom-domain configuration is always painful, so we wanted it to be easier to use or, at the very least, explained clearly enough to make the process straightforward.
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.
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.
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.
Technically, when we say “AI-assisted”, we, of course, mean “LLM-assisted”, but “AI-assisted” is the commonly used term. ↩︎