4 ms·

This is where we're at too. We've long been evangelizing Mailchimp and Mandrill in our product, and as a result have sent plenty of customers their way. In fact

by nhangen 11y ago

This is where we're at too. We've long been evangelizing Mailchimp and Mandrill in our product, and as a result have sent plenty of customers their way. In fact, our product almost relies on them as a pair. Now, because of the ToS, we have to remove it from our product and port our users somewhere else...and fast. We also have to port our own servers to another service, and fast. I remember the day we finally had enough subscribers to actually start paying Mailchimp money, and now all I can think about is how much disdain I have for them. Unless they reverse course on this issue, we will be shouting "down with Mailchimp" from the rooftops to all of our customers.

Bluestrike2 11y ago
Even if they reverse course (or just delay it for a bit longer to give their users more time to switch), I think people are going to be shouting "down with Mailchimp" for quite some time. It's really hard to trust someone after they've screwed you thoroughly.
ibmthrowaway218 11y ago
> We also have to port our own servers to another service, and fast. Once you've done that you should look at what other services you rely significantly upon and see about mitigating the risk there by having an alternative ready to go (or even sharing the load). At a previous startup we realised we relied wholly upon Mandrill and so reimplemented the sending code so that half of the emails went out via Mandrill and the other half by SendGrid. A stunt like the above just requires a quick reconfigure to make all emails go via the alternative provider whilst we (with less panic) add another new alternative provider to share the load. It also helps build up a positive reputation before cutting over straight away. (This wasn't about splitting the emails amongst free tiers to keep it free, we were far away from moving up to a paid tier even with all emails going through one provider.)
- robalfonso 11y ago
  Great minds, we did the same thing though, we always sent 100% through mandrill just to be able to investigate delivery issues more simply, quick change and send grid is up and elasticmail.com is looking good
- dchesterton 11y ago
  We're doing the same. I re-wrote our code over the weekend from sending solely through Mandrill, to splitting our traffic 50/50 between SendGrid and SparkPost. I'm going to implement a similar strategy for some other external services we rely on and I've open sourced the Go code [1]. This also has the benefit that if one service goes down, we can automatically fallback to the other with (hopefully) no downtime. Most email providers have a limit to what you can send until you're established with them, so using another provider as a standard backup isn't feasible, as suddenly sending 1,000's of emails a day will see the account get suspended pretty quickly. Plus, if one of them goes out of business or changes their terms with little notice, like Mandrill, we should have a bit more time to work around it as at least one service will work. [1]: https://github.com/dchesterton/go-service https://github.com/dchesterton/go-service

by nhangen 11y ago

Bluestrike2 11y ago

Even if they reverse course (or just delay it for a bit longer to give their users more time to switch), I think people are going to be shouting "down with Mailchimp" for quite some time. It's really hard to trust someone after they've screwed you thoroughly.

ibmthrowaway218 11y ago

> We also have to port our own servers to another service, and fast. Once you've done that you should look at what other services you rely significantly upon and see about mitigating the risk there by having an alternative ready to go (or even sharing the load). At a previous startup we realised we relied wholly upon Mandrill and so reimplemented the sending code so that half of the emails went out via Mandrill and the other half by SendGrid. A stunt like the above just requires a quick reconfigure to make all emails go via the alternative provider whilst we (with less panic) add another new alternative provider to share the load. It also helps build up a positive reputation before cutting over straight away. (This wasn't about splitting the emails amongst free tiers to keep it free, we were far away from moving up to a paid tier even with all emails going through one provider.)

robalfonso 11y ago
Great minds, we did the same thing though, we always sent 100% through mandrill just to be able to investigate delivery issues more simply, quick change and send grid is up and elasticmail.com is looking good
dchesterton 11y ago
We're doing the same. I re-wrote our code over the weekend from sending solely through Mandrill, to splitting our traffic 50/50 between SendGrid and SparkPost. I'm going to implement a similar strategy for some other external services we rely on and I've open sourced the Go code [1]. This also has the benefit that if one service goes down, we can automatically fallback to the other with (hopefully) no downtime. Most email providers have a limit to what you can send until you're established with them, so using another provider as a standard backup isn't feasible, as suddenly sending 1,000's of emails a day will see the account get suspended pretty quickly. Plus, if one of them goes out of business or changes their terms with little notice, like Mandrill, we should have a bit more time to work around it as at least one service will work. [1]: https://github.com/dchesterton/go-service https://github.com/dchesterton/go-service