One problem people seem to have with the new pricing is the sudden transition between 0$ and 9$. The change to "max(9$, used billable quota)" from the earlier "$9 + used billable quota" is nice, but still makes the gap somewhat jarring. I was thinking, can't there be a middle ground between:
1) small fixed quotas, min $0, max 0$ 2) very large fixed quotas, min 9$, max unlimited$ What is the rationale for the $9? To recoup the losses from the $0 loss leader? To support the cost of the free quota that paid apps receive (e.g. 24 free IHs)? To provide guarantees for serious apps? (how so?). Consider offering a billing class which doesn't need to be particularly generous regarding fixed quotas, but is more elastic than "max $0 billable quota". That would allow for, say, a web service which has very low traffic but needs 600 MB of HR storage. BTW: looking at the price of reserved front-end instances, if one had to allocate all of the provided free front-end instances, that would cost 0.05$ * 24h * 30d = 36$ per month. So the 9$ now seems cheap. But why bundle all that and charge the 9$? You are offering 720 free monthly instance hours. Many people won't be needing that, just the elasticity that comes with billing. So just let people buy a whatever amount they need. Some will need less, and will pay less. Others will buy more and pay proportionally. -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
