Switching from Mailchimp to open-source Mailtrain and AWS SES

At a previous job, all API errors were emailed to internal email lists.

The dev monitoring the API health kept track of system health by looking at the number of unread messages in his inbox. If the number of unread messages went up by < 100,000 in a day, the API was doing fine. If there were a couple million new messages, it means we were having problems.

So... I can definitely see how this is plausible, if not uh, "best practice".

Not to mention the free tier.

There are many ways to measure the cost of something like this, but a blind look at average salaries is probably the worst. It doesn't factor in overhead or opportunity cost. In most companies, having a developer spend a week on maintenance of a system which isn't a core business value doesn't make sense. They would be much better utilized on value added work. I guarantee you most engineers could delivery way more than $500 in savings in a week.

The cost to the company per engineer hour is significantly higher than the engineer’s hourly rate.

I think it is actually closer to ~16 hours a year assuming the lower end of the range you suggested, and dramatically less if this person makes more than that.

Most simply, I think the typical calculation is if there were 40 working hours per week (8 hours, Mon - Fri) then there are 2080 working hours per year, which is ~21.63 Euro (per hour, assuming 45k EUR) just in salary - other commenters pointed out an employer would have other costs, but lets try and keep it simple as was suggested.

But beyond simple, you don't work on public holidays and Europe tends to have 20-25 vacation days per year as well. That probably adds up to 35 days (280 hours) in France. Therefore the number of hours actually 'at work' is only going to be 1800 a year, so 45k EUR comes to 25EUR per hour.

I imagine this might work on AWS Free Tier but while SES supports ~62k emails per month as 'Always Free', any EC2 instance or network bandwidth is probably billable here. There's probably up to 100EUR a year in cost associated here?

So you have 400EUR of money Mailchimp charged for the service and will never be "apples to apples" because now you're responsible for initial setup and ongoing maintenance. Definitely seems simple in the blog post, but unmentioned was how you backup all the configuration and state, how do you monitor it, most of the features of Mailtrain (e.g. Click Stats) rely on the NodeJS application being operational so is this actually a load balancer, two instances, and the extra complexity of database replication, et al? It is also now on you to make sure it stays patched, isn't compromised, etc.

I imagine there are different deliverability promises with Mailchimp vs. Amazon SES and you might now have to do more managing of that through AWS interfaces?

All of the above needs to fit into ~16 hours a year if we're going to draw this comparison against what you'd make as a salaried engineer. All of the above is time that could have been spent on extra content for the newsletter, or improved content for it, other than this post obviously, or on audience building, on other professional development, or just about anything else.

I think the ROI of writing the article and making everyone debate this on the internet was pretty high, but the title feels like clickbait. This is a straight trade for saving a little money vs. a semi-significant personal time investment.

Not FUD there has been a court ruling on using mailchimp being a breach of GDPR.

Wasn't that just the latest iteration of "EU pretends no other country in the world has similar national security laws to its own member states", under which multiple EU-US agreements on data sharing have already been struck down and technically any EU business probably can't use any US-based service ever if that involves sharing of personal data? Did this one get to the end of the process and result in a real fine or other penalty?

My understanding is that it applies globally, regarding data collected on EU citizens. Enforcement is obviously a question here.

I agree. When testing the various SES was more involved but seemed to work fine. If you follow the standard procedures and aren’t a spammer (even a respectable spammer) it should work fine.

But the users might make different choices if they knew how often mail they probably want to receive isn't reaching them. The problem at the moment is that the failures are largely silent from the user's point of view. To be fair to GMail, although it's obnoxiously aggressive with classifying things as spam, as far as I know it doesn't silently drop incoming mail without notifying either the sender or recipient, which is the worst thing that some major ISPs do.

I have had customers contact my business to ask for help with something, and we send them a quick reply answering their question, and then the next day we get a frustrated follow-up asking why we are ignoring them, and this continues for another round or two until they give up on buying something from us or cancel a subscription.

I have had friends send me a reply a month after a big party saying they're sorry they didn't make it but they only just found the invitation and the follow-up I sent them in their junk folder.

Those sorts of cases are annoying and seem to happen all the time these days, but imagine if a missing email was something really important from your doctor or your kid's school.

I don't really buy that excuse any more. This is a business that wants to have heavy, fast-moving objects automatically navigating complex and unpredictable transport networks using its software. For that matter, this is a business whose golden goose is prioritising content people most want to see on the scale of the entire WWW, which has no shortage of junk sites that exist primarily to game the system. I'm reasonably sure that same business can be smarter about spam recognition than defaulting to assuming new mail from a source it hasn't seen before is bad, which seems close to the practical output of its existing system. But as with so many of the current dominant tech businesses, until someone poses a credible threat to its existing business model and revenue streams, it has no reason to invest in fixing problems even if it could obviously do better.