> How fast they will get more could depend on the current value of their account, where the value could be calculated from the credits and the number of subscribers they have.
So are you then implicitly setting the price yourself because anyone who doesn't charge enough can't get more credits?
Suppose someone develops an app which takes hardly any effort to make -- it's a hundred lines of code -- but it does something common that everybody needs so if available for $0.01 it would have a hundred million users. Which would gross a million dollars and more than pay for the development of the simple app, so the developer is satisfied with that. But to do that you'd have to let them sell a hundred million subscriptions for $0.01 each.
Now let's go toward the other end of the spectrum. Some app which is specialized and requires a million dollars of developer time but only has a market of 10,000 customers. Those customers would pay $100 each for it, if they had to, but not if they can buy into the system somewhere else for $10 (or $0.01) instead.
In general, who is going to buy a fungible subscription for significantly more than it's available somewhere else? How do you handle the fact that the development cost of a thing isn't proportional to the number of people who use it?
> So are you then implicitly setting the price yourself because anyone who doesn't charge enough can't get more credits?
Everyone can get more credits. The idea is that when we think we need more subscriptions to sell, every developer would get a number of additional credits that is proportional to the number of credits they have (with active subscriptions converted to credits for the calculation).
> But to do that you'd have to let them sell a hundred million subscriptions for $0.01 each.
That would be very difficult for them to do since the number of subscirptions they can sell is limited by how many credits they have.
> Some app which is specialized and requires a million dollars of developer time but only has a market of 10,000 customers.
If you make software for only a few people and you need a lot of money then I don't think this system is for you. It is mostly for developers who make software for everybody.
> Everyone can get more credits. The idea is that when we think we need more subscriptions to sell, every developer would get a number of additional credits that is proportional to the number of credits they have (with active subscriptions converted to credits for the calculation).
This is what I mean by implicitly setting the price. You set it indirectly by rate limiting the number of subscriptions.
A service with high cost and low volume gets priced out, even if it's only somewhat above average, because people can buy a subscription from someone else for less.
Conversely, if subscriptions are rate limited then no one has any incentive to sell them for less than the market rate, which is in turn set by supply and demand (and you having your hand on the supply knob). Why would anyone charge less, or pay more, than the median price?
Then anyone who needs more than that is priced out, and if you allocate credits based on how many people sign up or use a service, the service that provides only trivial value but to a large number of people gets a ton of credits disproportional to the value of their service.
So are you then implicitly setting the price yourself because anyone who doesn't charge enough can't get more credits?
Suppose someone develops an app which takes hardly any effort to make -- it's a hundred lines of code -- but it does something common that everybody needs so if available for $0.01 it would have a hundred million users. Which would gross a million dollars and more than pay for the development of the simple app, so the developer is satisfied with that. But to do that you'd have to let them sell a hundred million subscriptions for $0.01 each.
Now let's go toward the other end of the spectrum. Some app which is specialized and requires a million dollars of developer time but only has a market of 10,000 customers. Those customers would pay $100 each for it, if they had to, but not if they can buy into the system somewhere else for $10 (or $0.01) instead.
In general, who is going to buy a fungible subscription for significantly more than it's available somewhere else? How do you handle the fact that the development cost of a thing isn't proportional to the number of people who use it?