4 ms·

The big challenge with the freemium model is that there needs to be enough of a separation between what is "free" and what is "premium". If the free version co

by dshah 18y ago

The big challenge with the freemium model is that there needs to be enough of a separation between what is "free" and what is "premium". If the free version contains too much, people don't have enough of a cause to upgrade to premium. Too little, and not enough people use the free version. As for simply charging for uptime, the issue is kind of a "tragedy of the commons". If everyone is benefiting from the increased uptime, the folks paying the premium don't really have an incentive to pay. Finally, one of the big challenges of Twitter is that even getting folks to use the free version is non-trivial.

nostrademons 18y ago
The way some sites (eg. LiveJournal) have handled that is to have paid users hit a dedicated cluster. Since the number of paid users is limited (and they're paying, so you can always add more hardware), response times to the paid cluster are usually super-fast. It also has a neat viral growth aspect - several times when LJ was running slow, I complained to my friends, "Damn, LiveJournal's moving like a snail today" and they replied "Not for me. Paid account. :-)" Still didn't get me to buy, but there's a certain social pressure when they can use it and you can't. If the app hasn't yet scaled to multiple clusters, you can do something similar with an interlock that dumps the user out to a static page if server load is too high, without making any queries to the DB. I've done that on a nonprofit website, and if we'd been able to charge, it would've been trivial to check a paid users table first and let them in if they're paid, otherwise exiting with a "Server too busy" message. Heck, you could even redirect to the account signup page, saying "Our servers are overloaded now. Help out with a paid account! You'll get access ahead of all the freeloaders" and let them signup immediately.

by dshah 18y ago

nostrademons 18y ago

The way some sites (eg. LiveJournal) have handled that is to have paid users hit a dedicated cluster. Since the number of paid users is limited (and they're paying, so you can always add more hardware), response times to the paid cluster are usually super-fast. It also has a neat viral growth aspect - several times when LJ was running slow, I complained to my friends, "Damn, LiveJournal's moving like a snail today" and they replied "Not for me. Paid account. :-)" Still didn't get me to buy, but there's a certain social pressure when they can use it and you can't. If the app hasn't yet scaled to multiple clusters, you can do something similar with an interlock that dumps the user out to a static page if server load is too high, without making any queries to the DB. I've done that on a nonprofit website, and if we'd been able to charge, it would've been trivial to check a paid users table first and let them in if they're paid, otherwise exiting with a "Server too busy" message. Heck, you could even redirect to the account signup page, saying "Our servers are overloaded now. Help out with a paid account! You'll get access ahead of all the freeloaders" and let them signup immediately.