We've learned quite a bit about how to email developers and still continuing to learn to to best serve you all.
For instance, we started out sending html email, like we've seen other companies do. It wasn't nearly as helpful as personally emailing our new signups in plain text.
We've also experimented with newsletters like AWS does and targeted emails based on weekly actives and other metrics. In this, we're finding that the most effective emails match the relationship. If you are a current user, a short personal email works well. If you signed up a long time ago, a newsletter is relatively effective at getting someone to poke at it again, but also easy for them to ignore.
As you have discovered, we're also playing with frequency. I'd have to look it up in our db to be sure, but it looks like you happened to be in a small a/b test group that we've termed "eager". That in combination with being sent the monthly newsletter means you may have been emailed many times. I apologize for that.
We aren't big fans of spammy emails and we've been careful to watch the number of "spam reports" and been proud that it has been so low. However, it's good to hear this feedback from you so we can continue to learn.
I'm always happy to talk with customers; my email is liyan@filepicker.io.
Hey - just wanted to reach out and thank you for signing up for Filepicker.io. I'm the developer assigned to help you get integrated, so let me know if you are having any trouble, want to know more, or just to say hi. It's always fun to hear from our users. -Brett van Zuiden
Simple. To the point. No pressure.
Now that I know that this was sent out manually by Brett instead of just another spammy auto-responder I like it even more.
I'd rather have a developer contact me and really want a reply rather than some HTML newsletter with tons of information and sales tactics on it.
Getting this stuff right is really hard for an early startup. You don't send enough email and you end up forgoing conversions and engagement. You send too much and you're called a spammer. On top of it, you don't have enough data about your customers to know what is useful information or not so you end up sending vague emails about "need help getting started" or "check out links X, Y and Z" until you have enough data to actually make and send good emails.
We had problems sending too much email early on too. I would suggest segmenting your user base and sending them emails based on there activity on the site. It certainly helped reduce the spam complaints.
I realize it's hard but the onus is on the startup to get this right. In the process they'll piss off some users but that's the process.
Edit: A bit more context more my enthusiasm.
I really wish web services would start providing instructions for self-hosting all scripts.
If browsers had a way to let third-party scripts run in a sandbox separate from the site, so that (for instance) filepicker.io can help with file uploads without having the full permissions of the logged-in users on every site that uses it, I'd have much less objection to third-party scripts.
Took about 5 minutes to get image uploads enabled in our web app, including allowing people to take pictures directly from a webcam. No screwing around with file POSTs, sanitizing, storage, CDNs etc.
Looking forward to using it in a real project.
But that's exactly it - if you are in a hurry, you'd be more willing to create a dependency on 3rd party and take on the risks that you can avoid otherwise. I'm sure there is a market for filepicker-like webapp component services, I just suspect that their user base is going to be highly transient (edit - or hard to monetize on).
Filepicker looks neat. I wish it had been around when we were building our service.
Either be constructive or don't say anything. Both are good feedback for the startup. Being mean doesn't help anyone - the startup or the user.
Could it have been put in a friendlier tone? Sure, but I'd argue that his feedback is actually constructive.
http://www.daemonology.net/blog/2012-08-13-tarsnap-credit-ca...