Case Studies in Freemium: Pandora, Dropbox, Evernote, Automattic and MailChimp
gigaom.com
gigaom.com
I've found this to be absolutely untrue. Don't let implementation difficulty factor in the decision whether to charge for a feature or not. The only exception to this is when choosing not to do something altogether because it's too hard.
On Obsidian Portal, we charge for some of the simplest things (like the ability to send e-mail notifications of changes), while giving away some of the hardest things for free. In my opinion, it's about providing a useful product for free, while constantly presenting a premium product that would be more useful. The decision about what to charge for should only be made in terms of how useful it is to your users, not how hard/easy it is for you to do.
This was a lesson it took me a bit of time to learn. As a contractor/consultant I needed to figure out what to bill. I started out thinking in terms of how hard something was; if I had to bust my ass, then I was going to charge for it, and if something is easy, how can I justify a high rate?
Which, as it happens, is idiotic.
The real metric is, How much value am I providing?
Realistically there are some constraints, such as what are competitors charging (a concern if you don't want to chase potential customers away), but personal effort is not a main factor.
There's a belief that hard work should be rewarded, but that just encourages people to work hard regardless of the end value of their efforts. Valuable work should be rewarded. If you can do it with out breaking a sweat, more power to you.
You're kind of screwed if you go about thinking that because you worked hard on something that people will ultimately find it valuable and reward you. That only happens in some politician's stump speech fantasy.
There is the mindset that you'll win the lottery, get bought out, and become rich. It's all about users, not revenue. It becomes a lottery, where a few get very wealthy, and the rest make nothing. That's not Freemium, of course, that's "free", as in twitter, facebook, etc.. However, to me, Freemium is almost as bad a bet.
With Freemium, I end up burning so many resources with scaling issues, trying to service all of these non-payers, hoping I'll "win the lottery", by getting enough actual payers to finance things. The examples they gave were good cases in point of services that struggled under the load of the non-payers for a few years.
I would like to just charge from the get-go, and avoid the scaling issues that freemium implies.
If you give away too much, there's no incentive for users to pay for upgrades.
If you don't offer some sort of free account, it can be hard to get traction.
In the case of dropbox, it seems a lot of users are content with 2GB for free.
What would happen if they dropped that to 256MB. Would they get more conversions? Or would users simply move to a 2GB freemium competitor?
Hard to know what's best.
So, I'm still debating as my app is currently paid-only but this is a pretty important point to consider.
You need to do something to attract users, and allowing non-paid usage may be cheaper than the cost of additional advertising that gets people to sign up and pay.
Take a look at 37signals, StackOverflow, or FogCreek, for example, in terms of the scaling needs of real, stupidly profitable businesses. I think you could probably fit all three companies' hardware in my closet and have room left over.
Or, at the lower end of the scale, take my business. On a very good day I might get a thousand people to sign up for the software. That's a huge number for me (more people than I know in the entire world!), but it is a very little number for a computer, even a modest fraction of a modest server sitting in Slicehost's rack.
Also, since the definition of 'user' is pretty loose, you can't really use these numbers to make any assumptions about the cost of serving them. If a free user stops using a service, he doesn't cancel his subscription. A paid user does. Freemium users are also hard to distinguish from trial users since the two are often amalgamated.