How to price: Lessons learned from our first attempt(blog.filepicker.io)
blog.filepicker.io
How to price: Lessons learned from our first attempt
http://blog.filepicker.io/post/31472601361/how-to-price-lessons-learned-from-our-first-attempt
13 comments
Sort of meta, but I thought the blog post was really effective at bringing the new pricing to my attention. I had looked at filepicker before, but with the new Free plan not tied to bandwidth I'm really excited to give it a try.
Not to mention, the added benefit of the pricing plan as it stands is that I'm literally thinking in my head "I hope I have to pay for this someday soon!"
Not to mention, the added benefit of the pricing plan as it stands is that I'm literally thinking in my head "I hope I have to pay for this someday soon!"
I signed up for filepicker a few days ago, and when I saw this topic I was afraid free would be gone, but I actually really like the changes, and I had the exact same feeling. I calculated it out, and I hope I can afford to pay for the $99/mo in the future.
This strikes me as SaaS as having gone too far. Are people signing up for it? Isn't some sort of Jquery plugin more appropriate?
We think that good file handling is important for the future of the web. When we first started, we weren't planning and didn't want to build a company.
However, as we went on, we kept needing server side components to make things work smoothly. For instance, we handle large files upload by chunking them up and reassembling them, retrying parts as needed. Image conversion baked in and other components in the pipeline that we want to build also require servers, something that you can't do with a plugin.
We fully support plugin developments and we fix bugs or add features as we see them.
When we first launched, we had people emailing us asking to pay and we've been growing week on week so the developer need is there. Part of me is just as surprised as you are, until I write some code dealing when multipart form uploads or box's inconsistent error codes. Then I remember.
However, as we went on, we kept needing server side components to make things work smoothly. For instance, we handle large files upload by chunking them up and reassembling them, retrying parts as needed. Image conversion baked in and other components in the pipeline that we want to build also require servers, something that you can't do with a plugin.
We fully support plugin developments and we fix bugs or add features as we see them.
When we first launched, we had people emailing us asking to pay and we've been growing week on week so the developer need is there. Part of me is just as surprised as you are, until I write some code dealing when multipart form uploads or box's inconsistent error codes. Then I remember.
>This strikes me as SaaS as having gone too far.
Yeah I was pretty skeptical when these guys first launched. I mean why not just DIY?
But if you think about it doing file uploads across tons of services and platforms is a PITA. As much as we love to tinker and hack, when you do need to execute fast, there can be a downside to reinventing the wheel.
@filepicker - Congrats on the the new pricing model, it's a definite improvement. Free is always a great price!
Also given that files are stored on customers buckets I feel is a good move, as it prevents lock-in.
Yeah I was pretty skeptical when these guys first launched. I mean why not just DIY?
But if you think about it doing file uploads across tons of services and platforms is a PITA. As much as we love to tinker and hack, when you do need to execute fast, there can be a downside to reinventing the wheel.
@filepicker - Congrats on the the new pricing model, it's a definite improvement. Free is always a great price!
Also given that files are stored on customers buckets I feel is a good move, as it prevents lock-in.
Boutine had an Instagram integration already, but decided to use this instead. It was handy since it saved me from having to integrate with lots of third-party services myself.
I'm paying for it, but I'm not sure I would be if I weren't grandfathered into a $15/month plan... $100/month is a lot for my use case.
It does offer a lot more than any jQuery plugin does though, and doesn't require any server-side code. File upload is a huge PITA to begin with, not to mention integration with Facebook, Dropbox, Instagram, Flickr, webcams, etc, etc.
It does offer a lot more than any jQuery plugin does though, and doesn't require any server-side code. File upload is a huge PITA to begin with, not to mention integration with Facebook, Dropbox, Instagram, Flickr, webcams, etc, etc.
Just so someone else from your staff hears this, you guys are a bit too in your face with your repeat emails. I'd stop at one and if you don't get a response leave it at that.
You're sending messages without an opt out which could get your domain blacklisted in the long run. I'm not saying I minded, but just be wary :)
You're sending messages without an opt out which could get your domain blacklisted in the long run. I'm not saying I minded, but just be wary :)
Definitely- we're revamping it right now, look for another lessons learned blog post soon
Thanks to RideJoy, Fitocracy, Boutine, WeVideo, Vidcaster, and Ridepost for guiding us through the pricing change and offering valuable feedback.
OT: You may want to validate email addresses too during signup (not only password) - this will ensure that visitors can't leave the email field blank by mistake (and will avoid serving them your error page).
Great article btw.
Great article btw.
Another very good source on pricing experiments: http://conversionxl.com/pricing-experiments-you-might-not-kn...
Just in case you are not aware already, there are errors on https://filepicker_static.s3.amazonaws.com/ce7b147/* requests which means missing CSS and bootstrap.js at least for me.
Hi there. Looking through server logs and all services look a-okay. Feel free to send me an email at [email protected] and we can keep digging.
Wait, do I have to provide my own Amazon S3 bucket? Also, do you do any security checks on filetypes - namely content sniffing? That's my biggest concern when it comes to handling files, given IE's use of content sniffing to determine MIME type.
https://www.filepicker.io/faq/
Where are the files stored? We automatically save all uploaded files directly into your Amazon S3 bucket. To make it easier to get started, if you haven't put in your S3 credentials we will store them on our servers, but as your usage increases we will ask you to move to your own storage.
Where are the files stored? We automatically save all uploaded files directly into your Amazon S3 bucket. To make it easier to get started, if you haven't put in your S3 credentials we will store them on our servers, but as your usage increases we will ask you to move to your own storage.
I'm pretty sure you can specify the MIME types that the uploader will accept.
Does filepicker support restricting file types and validating file types? For example can I use Filepicker to bypass my own need to validate if a file is an image of a specific type (eg: png) or not?
I believe you can filter by mimetypes.
Correct. We currently do mimetype verification.
People have been asking for extensions as well, so that's on the roadmap as well.
People have been asking for extensions as well, so that's on the roadmap as well.
File type and size limits are specified in the JavaScript API, no? Is there any way to enforce it server-side, so people can't abuse it?
We enforce both the filetype and size limits on the server side.
We have some hostname verification and we also also adding in secret keys to sign requests so we can be even more sure.
We also have some checks that look for abnormal upload patterns that have found a couple oddities and will get better with time.
We have some hostname verification and we also also adding in secret keys to sign requests so we can be even more sure.
We also have some checks that look for abnormal upload patterns that have found a couple oddities and will get better with time.
But where can I specify filetype and size limits in my control panel? There's nothing stopping abusers from changing those parameters on the client.
That's a good idea. We had been working under the assumption that you would want to change limits often, but I can see how a per-apikey cap would prevent gross abuse.
It was good to see numbers (relative ones anyhow) for your switch from contact-for-quote to standard pricing. Do you have any early insight into your changes in revenue/signups from this new switch?
Given that we just switched from contact-for-quote to a new version of standard pricing (we had a old version which was confusing!)we don't have the numbers yet from the switch. Will post the results once we have them.
Pricing is tough! On one of my websites, still running after 10 years, I still modify prices quite frequently based on market conditions. Their is quite a bit of "art" in pricing.
A few months ago, I was launching an information product I had been working on for a few years. I was trying to decide how to price the product. I was planning to price it anywhere from $17 to $97.
In order to come up with pricing, I did some testing before the launch. I put up a sales page that wasn't linked from my main site. The 'Buy Now' didn't work on the page (It sent them to an e-mail sign up page instead).
Then I sent a ton of targeted adwords traffic to the sales page. I used Google Website Optimizer to split-test the page with a range of different prices: 17, 27, 37, 47, 67, and 97. Google Website Optimizer allowed me to see how many people clicked 'Buy Now' when they got to one of the pages. What I found surprised me.
The highest number were at 17 and 97, and were almost equal in number. The other prices 'sold' less. This to me meant that people were willing to pay 97. (I could have possibly gone higher but didn't want to charge my readers more than that.)
So I ended up selling the product for $97. It's been selling pretty well. After the launch, when the product was actually for sale, I did find out that people who click 'Buy Now', don't always buy. In fact sending targeted traffic to the page hardly sold any at all. A certain number would click 'Buy Now', but no one ever bought. Only people who came from my website bought the book.
Does this mean that my tests were off? No, I still think it was the best way I could have tested. A few weeks after the launch, without announcing it, I split-tested the real sales page for two weeks with my readers by selling it for 47 and 97. So at random, buyers would see 47 or 97 and could actually buy the product. The product sold almost an equal number at each price.