The cloud shooting itself on the foot: dispatch.io/.cc and do.com
< Next Topic | Back to topic list | Previous Topic >
Posted by steveylang
Nov 19, 2015 at 07:58 PM
Stephen Zeoli wrote:
>Though in thinking about this, I realize there are two distinct “cloud”
>issues here: 1. Trusting your data to the cloud for use on local devices
>with locally running apps. 2. Trusting cloud-based apps.
I think another distinction to be made here is between the product/service itself, and the business model. I just read a very good article this morning on the ‘race to zero’ for software pricing:
https://stratechery.com/2015/selling-feelings/
The following quote is about free-to-play games, but seems to apply just as well to free-to-use cloud services (with premium add-ons):
“Plus, just as is the case with free-to-play games, the economics are all in alignment: creating the market is a fixed cost which means it has no impact on the marginal cost of one more player. Why not add the maximum number of players (by making it free) and then develop a different revenue stream that pays out continuously the longer a player plays the game, ensuring the developer captures value as it is realized? Sure, said value may only be captured from some, and in relatively tiny increments, but remember we’re dealing with the Internet: you can make it up in volume.”
I don’t know that these sorts of models are good or bad for users, but I think they are inevitable for cloud-based startups. With no/low barriers to distribution, the price goes to near zero (depending on how well your product/service is differentiated.) So why not start at zero to maximize the user base from which you may or may not be able to create a small subscriber base? If you can attract a large free user base, you can then make the case to investors that there is a potential revenue stream to follow. If you can’t attract a significant user base with a free product/service, forget about revenue- you’ve failed the most basic litmus test and need to go back to the lab. For a cloud-based service can mean making changes to your service on the fly, that some of your customers may not want.
Posted by Dr Andus
Nov 19, 2015 at 09:04 PM
Part II of the WorkFlowy interview is worth reading as well, especially as it contains something of a roadmap (or at least a wishlist of the developers themselves):
http://blog.workflowy.com/2015/11/19/interview-jesse-mike-part-2/