After I signed up to this, I started getting an e-mail everyday. All e-mails are titled like "Do you need help?" "Let's get you started with filepicker" etc etc. WTF is this? What is this rush for? I just gave a try your app, that's it. It sounded useful at first but you are losing respect by spamming.

Hi there. We think it's super useful too and therefore really excited to help developers onboard.

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.

Here's the email I just received when signing up (which I did right before Googling "Filepicker.io Hackernews" to find out more about HN's take on this service):

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.

They might have seen this: http://www.kalzumeus.com/2012/05/31/can-i-get-your-email/ (You Should Probably Send More Email Than You Do)

This stuff is hard to get right. I think the answer for most web apps is to shift more towards trigger based emails, and then to measure how particular rules change customer behavior over the next 24 hours, week, 30 days, etc. Rather than an "A/B" test per se, you really need to split customers into 2 groups and intentionally not send an additional email to a group.

I would give them a break. Rather than just criticize them maybe provide useful feedback about content they could send you or why you think the emails weren't useful. If you don't like the emails just hit reply and tell them why. I'm sure they'd happily adjust what they are sending out based on good feedback.

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.

That's the startup's problem and not their users. It's too much work to reply to every email you get which you wish you didn't.

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.

True, but it wasn't too much work to find a HN thread about it and complain there.

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.

While combataircraft's tone isn't the nicest, he's voicing exactly what he's unhappy about, giving the Filepicker.io guys the information they need to improve in the future.

Could it have been put in a friendlier tone? Sure, but I'd argue that his feedback is actually constructive.

So far I've been really pleased with the help I've gotten from the filepicker.io guys. I considered the emails I got from them to be an indication of their genuine desire to help developers get started with the product rather than spam.

Can't recommend Filepicker enough. If your product involves any sort of document/photo access, you should try them out! I've been using it for a few months and have been pleased with the integration friendliness for a web-first developer like myself, the enthusiastic support (of course, small team, we'll how it scales), and variety of services connected. I especially like the "filter services by mime type" feature. The "save to" is massively useful from a consumer perspective as well.

Edit: A bit more context more my enthusiasm.

I like the concept of filepicker.io: a standardized widget for providing files that handles local files, remote URLs, and services people use. However, every time I read the phrase "by inserting a few lines into their source code", I think 'yeah, and one of those is a script tag pointing at a third-party server'. And sure enough, looking at the documentation, I see exactly that.

I really wish web services would start providing instructions for self-hosting all scripts.

If you self-hosted the script then it wouldn't be able to communicate with their servers, I think (someone can correct me).

We currently try to push people towards pointing the script tag to us so that we can more rapidly iterate on the product.

I understand the motivation; that doesn't make it acceptable for all sites, especially sites that care about minimizing their vulnerability surface. And since browsers don't currently have any security model for third-party scripts other than "full capabilities of the site that loads them", third-party scripts significantly increase the vulnerability surface of a site.

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.

You can run their scripts in an iframe, e.g.:

http://www.daemonology.net/blog/2012-08-13-tarsnap-credit-ca...

Yeah, I normally do that when dealing with APIs that want to use third-party scripts. I'd just like to see more APIs that support running with local versions of the scripts, to avoid the need for a separate untrusted domain.

When I first heard of filepicker.io I thought it was a stupid idea. File uploads aren't hard to do, after all, so why pay a third party service for it? However, used Filepicker at the NY eCommerce Hackathon recently because we needed to implement file uploads in a hurry and was very impressed with it.

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.

> ... in a hurry

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).

Getting customer data into your system is harder than it looks. Flash uploaders are pretty crappy, but you need them for IE users and direct to S3. Flash is broken for mobile, of course, as is the whole 'upload from computer' concept. Box, DropBox, Google Drive, flickr, and everything else is extremely popular, so if you start implementing all those yourself it adds significant development time and code to maintain. Filepicker has been a huge win for us at PlanGrid.

Just FYI, for xhr to S3 you can set up a proxy which fakes the CORS headers. You might have already been aware of that.

Filepicker looks neat. I wish it had been around when we were building our service.

That explains why nearly every Filepicker blog post makes it to the front page! :)