The Mandrill Debacle

`In Search of a Mandrill Alternative

The Mandrill Debacle

If you’re not familiar with Mandrill, it’s the transactional email service that powers the bulk of MageMail email that gets delivered.

What that means is that they handle the heavy lifting of sending emails out, dealing with mail servers and ISPs. We tell them what email to send and who to send it to, and they take care of the rest.

They made an announcement yesterday that has been pretty shocking and disturbing for most Mandrill users – that Mandrill is becoming a paid add-on to Mailchimp and they are forcing users to purchase a Mailchimp account or discontinue their Mandrill account.

Before I dig into why this is such a big problem, let me first give a bit of back story on Mailchimp and Mandrill.

If you’re reading this, you’re likely already familiar with Mailchimp – they are an extremely popular email marketing software for thousands, if not millions, of users worldwide.

A few years back, they spun off Mandrill as a standalone transactional email service – it’s an entirely separate company with an entirely separate purpose and customer base that it serves.

And Mailchimp has got to be one of the most beloved web-based companies on the Internet – virtually everyone that I know loves them – they have a great company ethos, have built
an amazing product, have a friendly team, good support – the list could go on.

I’ve been a huge fan of Mandrill ever since I first heard about it and started using it.

I’ve referred probably a few hundred customers to them directly, and I’m also a paying customer of them myself. Many of my customers have their own Mandrill accounts which we use to power their MageMail email delivery – and others use subaccounts of my main Mandrill account.

They have great support (not unlike Mailchimp themselves), a great API, and awesome email deliverability. I recommend them heartily to everyone that I come into contact with.

When they first launched and for quite a while therafter, they had an extremely generous free tier – they offered up to 12k emails per month completely for free.

I had many customers that were on a free Mandrill account for the entirety of their email marketing and transactional email needs for their online stores.

In July of 2015, they actually did away with this free tier. They replaced it with a free trial offering up to 2k free emails one-time and that’s it.

While this did come as a bit of a surprise, I actually wasn’t bothered by it. Look – businesses need to make money – and their free tier was simply too generous – there’s no way they could have been operating that profitably.

At that point, more of my customers started taking me up on the offer to use a subaccount of my main account so they wouldn’t have to pay for their own accounts, and I started paying significantly more in Mandrill fees.

**And I really wasn’t bothered about it.**

What they are doing now is quite a bit different from a simple pricing increase – it’s really completely out of left field and not consistent with what Mandrill is as a product offering.

So the announcement that they made yesterday is that all Mandrill users will be forced to have a paid Mailchimp account in order to continue using Mandrill – otherwise their Mandrill account will be closed down.

For people that do happen to use both Mailchimp and Mandrill – this obviously isn’t a big deal – and I’m sure there is a certain segment of the Mandrill user base that falls into that category.

But the problem is that Mandrill itself is simply an entirely different offering from Mailchimp. That’s why they spun it off as a separate company to begin with!

There are loads of Mandrill users that simply have no need whatsoever for Mailchimp – heck, there are Mandrill users that are building *competitors* to Mailchimp on top of Mandrill!

It’s not unlike AWS. There are tons of ecommerce businesses that are built on top of AWS. There are even stores that compete (at least partially or perhaps indirectly) with Amazon that are hosted on AWS.

**Can you imagine Amazon turning around and telling those users that they had to now sell their products through Amazon.com instead of selling through their own online stores?**

When you, as a business, decide to spin off a separate business that’s dedicated to infrastructure, *you’re making a commitment to provide infrastructure to your customers.*

In terms of the pricing, it’s not entirely clear to me what the impact will be. On the low end of things, you need to pay for a $20 Mailchimp account – if that’s something that you can actually use, that probably isn’t a horrible way to spend $20.

On the higher end, I’m really not sure how things will be handled.

Let’s say I have a customer with 1 million email subscribers (in the form of customers and newsletter subscribers combined). They are using MageMail for some ecommerce triggered email and they already have an ESP that they use for their newsletter blasts – which they’re likely paying $1k or several thousand for already.

Assuming that Mailchimp will count each unique transactional email recipient as a contact in your Mailchimp account, they would now have to spend $4,200 on a Mailchimp account that they don’t even use.

On top of the changes to pricing, there are changes to the terms. This is a snippet that I found over on a good Hacker News thread on the topic:

Also, it appears according to the Mandrill blog post that Mandrill is no longer supposed to be used for marketing email at all. So even if I do have customers that are on Mailchimp and don’t mind having a separate paid account, it appears that MageMail’s usage of Mandrill as transactional email delivery service of marketing email is no longer allowed:

To make matters worse, their silence on this whole thing has been deafening. To my knowledge, they haven’t even acknowledged the extreme and loud responses from their customer base with a simple “hey, we’re listening – we hear you and are looking into things”. I posted a comment on their blog, as did many other people, and as of this morning none of the comments had been moderated yet.


It’s just very bizarre that such a well-loved company would make such a drastic and painful change to a product that probably over a million people use, and that their handling of it would be so completely tone-deaf.

The way they described the amount of time they’re giving customers to migrated was also something that you have to laugh at just to keep from crying.

They say “We want to give everyone plenty of time to research their options and decide whether they’d like to create a MailChimp account… current users will have until April 27 to merge the accounts”.

**That’s about 2 months.**

Now for people that have a very basic, single SMTP integration, that could be more than enough time.

For people that have built complex web apps on top of Mandrill, including things like:

– sender reputation monitoring
– webhook handling for click / open / bounce tracking
– API retry logic
– Batch / template sending

…it’s not nearly enough time. Not to mention that I have hundreds of customers that I have to communicate with and get them to migrate over.

And let’s not forget that these customers are going to (rightfully) be annoyed with those of us that have so heartily recommended Mandrill, and are now turning around and telling them that their account is essentially going to be killed in 2 months.

Several people have requested a longer transition time for existing customers:

I think that 6 to 9 months would be much more reasonable.

While part of me hopes and expects that they will respond to the general outrage and at a bare minimum consider extending timelines and/or grandfathering in existing customers, it seems like a bit too much trust has already been lost.

Moving forward, I’m beginning to analyze alternatives to Mandrill. Thanks to Jeremy over at 86pixels.com who put together a list of alternatives. I’m putting together a spreadsheet where I’m comparing things like:

– API support
– Support for batch sending over the API
– Average customer support response time
– Flexibility for handling accounts that may have a temporary dip in sender reputation (something Mandrill was quite good about)
– Pricing
– Whether they have a free tier
– Whether they have a Sender Reputation metric accessible over the API
– Whether their business is dedicated to transactional email
– Whether they allow for marketing email to be delivered
– etc.

You can take a peek at the spreadsheet here and let me know if there’s any feedback you have or other data that you think I should collect:

**UPDATE FEB 26**

Ben Chestnut, the Mailchimp CEO, finally started replying to comments over on the Mailchimp blog. Makes me feel a lot better that there’s a human actually responding to all of the angst
over this.

This was his reply to Angel:

And his reply to me:

And my reply back to him:

I’ve also begun implementing logic on my end to be email-service-agnostic in order to work around this issue. Pretty close to having the basic sending functionality taken care of – will take longer to get things like analytics and reputation monitoring done, as well as some of the more involved functionality in MageMail v2 – webhook handling, etc. Have also been communicating with a number of the different transactional email vendors and updating the spreadsheet as I go.

**UPDATE MAR 1**

No reply yet from Ben to my reply on Feb 26. I did end up hearing from someone named Tony over at Mailchimp – interestingly enough he actually reached out to me personally shortly after the announcement.

They may offer me a 90 day extension but I’m still not clear on whether that will apply only to my account or also to all of my customer accounts.

And even if they do agree to it, I’m still not sure I want to risk trusting them to actually deliver on it, given the volume of support they’re likely experiencing and the fact that it’s clear they don’t care about me as a customer anyways.

On the selecting-a-new-email-provider front, I’m leaning towards Sendgrid right now – should be finalizing a decision in the next couple of days and will provide some more information
on the thought process there.

I wanted to also reply to a common response that I’ve seen in a few places, exemplifed here by this tweet from my buddy Ben:

 

Well, first off, I’m not even sure that this is true. Mandrill is a separate product with a separate team on it – so while they may not be a separate company technically speaking, they might as well be.

This is kind of like saying that Amazon can’t both please their retail customers and their AWS customers at the same time.

They seem to be doing a pretty decent job of it thus far.

But let’s assume, for the sake of argument, that it is true that they can’t please both types of customers without compromising.

I’m definitely not opposed to the idea of a company realizing they are maybe spread a little too thin and deciding to refocus on their core strengths. It’s what Apple did when Steve Jobs took the helm and killed several product lines all at once.

And, it would be one thing if they came out and said listen guys we’re bleeding over here really badly and simply cannot keep this running any longer – we have to kill it in 2 months or else it’s really going to hurt us as a company.

If they said that, I think people would, while still annoyed, actually rally around them and support them.

But the fact is – *they’re going to keep both products!*. And they’re doing totally fine (I assume and pretty much the rest of the Internet assumes) as a company. So in all likelihood it would be totally reasonable for them to grandfather in existing customers (let’s even just say we’re talking only about paid customers for a second here – you’d think that a paying customer might be a tiny bit of consideration).

Look at Basecamp’s policy on grandfathering existing customers on older products and you’ll immediately recognize it’s the right way to do things.

Even when they release new versions of Basecamp and they stop working on older versions of the product, they allow customers that are on the older versions to stay there forever. And here’s the beautiful thing – the bulk of your support and maintenance costs for a product are related to new feature development, new customer onboarding, and the bug fixing that inevitably comes up when you’re constantly building new features.

When you allow older customers to stick around on an old product and you expressly say that you won’t be building new features for the product and you won’t be accepting new customers at all, there ends up being a lot less support and maintenance costs.

Those customers hardly need any support because they’re already familiar with the product, and your bug fixes are kept to a minimum because you’re not building new features, and your hardware costs are pretty stable because you’re not onboarding new customers.

So no, I don’t think the way they handled this is in any way validated by the fact that they want to focus on their core strengths and consolidate the products. There are 100 ways they could have accomplished the same goals in a much more reasonable way.

*UPDATE MAR 2*

There is a neat little comparison of transactional email providers here:

*UPDATE MAR 3*

I’m going with Sendgrid – more info on this follow-up post.

Leave a Comment