I routinely think about by my business model and the repercussions of losing access to an online service. I backup incessantly as a result. BRB, going to backup my MailChimp lists.
You might want to consider removing "fucking" from your front page. I'm really not one to bat an eye at any form of cursing but seeing it on a company's webpage like that doesn't sit well. You have a good idea, let the tech speak for itself, no profanity needed.
If they went out of business then I would also assume they would give customers at least several months to export their mailing lists.
Edit: for some reason I'm not allowed to post new comments (presumably because of the downvotes to my other comments), so I'll just reply here: Would it be naive/fraudulent to promise the same durability as the storage service you're using? After all you're just feeding the data to their service through their API. I of course wouldn't promise this kind of up-time, but once the data is successfully saved then I fail to see why it would be wrong to make such claims. Assuming you also made regular backups of the data you feed to their services (which I certainly hope MailChimp do) then you can be even more confident that the data won't be lost. If Google/Amazon banned the accounts storing the mailing lists then I'm sure it could be recovered, especially by a company of MailChimps size.
I think it's okay to extend your durability promise to your clients, but durability isn't the same metric as availability as you've eluded to in your edit. I typically tell customers our product's durability is an extension of AWS's via a BAA. If I had to shut down a product and needed to provide the data for export, it would be simple to throw them in AWS s3 by client ID and let them sit there, but you're going to have to budget a big chunk of money for it. The only way you get a green light to have that budget is if you are contractually bound to do it. I believe a lot of companies (mine included) do have those contractual obligations in place already, but I honestly don't think what I have in mind to meet the contract, and the user's expectations are aligned. Is it the raw data they passed via API that I return or the enriched data we produced that I return? If it's the latter, we're going to need more money as that will be exponentially more information to store for export.
Those numbers are not the 99.999% you quoted and you really shouldn't think they are. If you promised your customers five nines reliability based on the one-two nines of your free suppliers, that's somewhere between disingenuous naivete and fraud.
What about when accounts are locked for users due to $reasons? What do those downtimes look like? I've heard enough horror stories to be wary of any one provider.
I hope that in the future, schools will also teach some basics of computer hygiene in IT classes, and how to behave on the internet.
Things like what internet services are, why backups are important, and how to practically do them, how to evaluate risks when communicating on the internet, how people are harmed on the internet (typical scams, phishing, running untrusted programs, ransomware,...), what privacy is on the internet, how to choose passwords, etc.
It would be wonderful if we taught people how to navigate the digital age. It would be similar to a driving course or personal finance. I know I had none of the above when I went through school, so I won't hold my breath, but I would support an initiative to provide more practical skills in school.
You're saying you never used service X, yet you would absolutely trust service X and assume that even when service X is out-of-businness, you can access data related to you.
That's very surprising to read, I'm exactly the opposite - own your data, don't trust any service, they always can go away, at any random moment.
This makes me wonder, what is more popular? Absolute trust or -ENOTRUST?
Edit since I can't reply: We're talking about durability of their mailing lists, not uptime. At least that's my intention. That Google/Amazon or MailChimp might experience downtime doesn't have any impact on the durability promises. I would also expect MailChimp (rather than all their customers) to do regular backups.
You absolutely have to consider TOS, account disablement, and other service provider-caused downtime.
And from what I've seen, no uptime calculation adds in account issues like this. And I'd really like to see how fast their resolution is.
Lesson learned.
But Mailchimp really should be making it easy for you to make your own mail backups!