4 ms·

I think your pricing scheme[1] could put a lot of people off. I fall into the category where I'd be fine on the free tier (< 10 private services), and yet I don

by Jake232 11y ago

I think your pricing scheme[1] could put a lot of people off. I fall into the category where I'd be fine on the free tier (< 10 private services), and yet I don't want a free service. I know if it's free, then it's going to be under some kind of fair usage policy, and you're going to rate limit me or have some kind of restrictions eventually. There's no way it can be sustainably free if I start to push it really hard. I'd prefer to just know the limits upfront, or have some kind of usage based pricing. [1]. http://stackhut.com/#/pricing http://stackhut.com/#/pricing

pea 11y ago
Hey Jake -- thanks for your feedback, that is really helpful. We're going to add some better pricing. How would you like this to work? - per month, flat rate, ups w/ usage - per request - per compute / storage We really like the idea of only paying for the compute you actually use a la lambda; one of my gripes with Heroku was having to pay $x when the server was only in use for short bursts. Why should I pay for downtime? That said, we've actually had many people say they would prefer per month, as it is more predictable and they are worried it could spiral out of control. I would be super interested to hear your thoughts.
- viraptor 11y ago
  Different person, but I'd prefer per-request with N requests packaged for free and (N+1)th request charged if charging is enabled, or returning error if I want to stay free. (so there are no surprise charges for service spamming)
- Jake232 11y ago
  I'm not sure that per-request would work; because the resources that a request takes can vary wildly in resources used / time taken. PiCloud (somewhat similar idea) used to charge based on processing time essentially (down to the millisecond I believe). I personally think that is the correct kind of pricing for something like this; but monthly plans including X time/requests would likely be a good idea.

by Jake232 11y ago

pea 11y ago

Hey Jake -- thanks for your feedback, that is really helpful. We're going to add some better pricing. How would you like this to work? - per month, flat rate, ups w/ usage - per request - per compute / storage We really like the idea of only paying for the compute you actually use a la lambda; one of my gripes with Heroku was having to pay $x when the server was only in use for short bursts. Why should I pay for downtime? That said, we've actually had many people say they would prefer per month, as it is more predictable and they are worried it could spiral out of control. I would be super interested to hear your thoughts.

viraptor 11y ago
Different person, but I'd prefer per-request with N requests packaged for free and (N+1)th request charged if charging is enabled, or returning error if I want to stay free. (so there are no surprise charges for service spamming)
Jake232 11y ago
I'm not sure that per-request would work; because the resources that a request takes can vary wildly in resources used / time taken. PiCloud (somewhat similar idea) used to charge based on processing time essentially (down to the millisecond I believe). I personally think that is the correct kind of pricing for something like this; but monthly plans including X time/requests would likely be a good idea.