4 ms·

It TOTALLY depends on the type of site/service/product. I'm currently involved in two very different models: ThatHigh.com - ad driven, completely free, entert

It TOTALLY depends on the type of site/service/product. I'm currently involved in two very different models: ThatHigh.com - ad driven, completely free, entertainment. There is no chance to pay for anything (well, I sell stickers, but that isn't something that generates much money). This site pays my rent through advertisements. Djangy.com - Heroku for Python. When we're ready for public beta, it will have a free version: basically enough to get something up and running. The paid features are scaling, addons, dedicated databases, etc. There's no way advertising would work here, for example. The numbers are a little tricky -- only a certain % of apps will be paid, so to break even or reach profitability means that the paying customers are supporting EVERYONE, which can be significant. You can imagine many different models -- Facebook, for example, and twitter. Then there are subscriptions that give you "credits", and then there's something like Twilio that you pay for in advance, and then your account is refilled automatically once it reaches a certain threshold. This trend of "pay for what you use" has some implications for the organization providing the value and charging -- namely, your product has to be ultra-efficient in order to compensate for the fact that your users are only paying for what they use, even though there may be lots of remnant resources that YOU are still paying for. It's definitely getting interesting!

erikb 16y ago
@your Djangy thing: I am a Django user and would love to have a Heroku for Django. But making it for free makes no sense. Make it ridiculously cheap if you like to, but to pay nothing for something that actually really produces simple to calculate costs is awkward. I wouldn't use that!
- endlessvoid94 16y ago
  Glad to hear your feedback. This model worked VERY well for heroku; now, the Python and Ruby communities are different, so perhaps we should examine that. However, note that it's just one free running app instance. Scaling will require payment, as will background processes and a host of other features.
  - shogunmike 16y ago
    Over time your userbase will form a power law distribution (in terms of success/scale) and you may end up having to support a lot of free users for a small minority of paid users. Folks already pay for hosting now - so why not charge them for all the added value you provide? This will scale in proportion to your infrastructure demands. I'm paying $20/month for a VPS slice that runs my blog. I'm sure there are plenty of people who'd be willing to pay at that price point for all of the added value that Djangy will provide, on top of hosting. There's no need to take my word for it though as this could be validated/tested quite easily.

erikb 16y ago

@your Djangy thing: I am a Django user and would love to have a Heroku for Django. But making it for free makes no sense. Make it ridiculously cheap if you like to, but to pay nothing for something that actually really produces simple to calculate costs is awkward. I wouldn't use that!

endlessvoid94 16y ago
Glad to hear your feedback. This model worked VERY well for heroku; now, the Python and Ruby communities are different, so perhaps we should examine that. However, note that it's just one free running app instance. Scaling will require payment, as will background processes and a host of other features.
- shogunmike 16y ago
  Over time your userbase will form a power law distribution (in terms of success/scale) and you may end up having to support a lot of free users for a small minority of paid users. Folks already pay for hosting now - so why not charge them for all the added value you provide? This will scale in proportion to your infrastructure demands. I'm paying $20/month for a VPS slice that runs my blog. I'm sure there are plenty of people who'd be willing to pay at that price point for all of the added value that Djangy will provide, on top of hosting. There's no need to take my word for it though as this could be validated/tested quite easily.