I don't know how many private repos I will be using in a year, so I pay for what I'm currently using. It may go up or down, and my plan will be adjusted accordingly.
If the problem isn't the on-my-credit-card-statement cost for the service that you'd use, and is instead a philosophical disagreement with how the cost is calculated... that's just a little bonkers.
See, that's the problem in thinking. People go, "Hmm, 10 repos cost $12, so that's $1.20 per repo. But if I have 11 repos, it costs me $22, it costs me $22 so it's $2 per repo, what a ripoff!" Or conversely how you stated it, "$1.20 per repo for the first 10, then $10 for the 11th, and the next 9 are free."
If they restated it that it costs $2 per repo, but if you order in bulk you get a discount, people would be happier. So even if they always paid $22, they'd be thrilled because the "real" prices would be 11 for $2 each all the way down to 20 for $1.10 each!
I think coderholic gave you a good advice. If you're on amazon with a pay per use plan, you should immediately do the math of what it's going to cost you if someone does 1M request a day.
Let's say someone who make an equivalent service, sells cheaper plans, and uses yours for example.
Why not offer both? In a manner similar to AWS, let me have the option to pay for a fixed amount at a slightly lower cost and pay for additional "as I go" at a slightly higher cost?
If I have no way to predict my baseline usage, I'll just stick to using the no-guarantee price. But once I have an understanding of a baseline usage amount, I'll commit to paying you in advance for a certain amount in exchange for a slightly lower rate. If I don't meet my goal/quota, I lose it. If I go over, I can buy more at the variable price.
Businesses simply build fees into their product/service cost. That it's 3% or 1.9% or whatever rate they can negotiate is largely irrelevant except for those businesses which focus entirely on price for commodities which are fungible regardless of provider.
If you run a SaaS company and your Pro service level costs $20/month, would you change your price to $19.40/month if you were able to eliminate credit card transaction fees? What if your service involved a little bit of manual data entry by your employees every month and you found a more efficient way to do that; would you reduce your monthly fee by the effective cost of the few seconds a month of employee time you've just saved? Perhaps drop it from $19.40/month down to $19.37 a month? Of course not. Whoever signs up for your service sees value in paying $20/month and they honestly don't care what your underlying fee structure looks like.
Ah, I see. You and I are just valuing things differently. Personally, I don't care about cost/MB nearly as much as I care about the "Amount Due" line of my bill.
Asking a million people to pay $0.01 per month is a small marginal cost. Asking one company to pay $0.01 for each of a million users per month is not a small marginal cost.
This sort of thing is pretty annoying to procure. Imagine you have 20 suppliers and they all have bespoke pricing arrangements, vs you have 20 suppliers, who each charge you X per active user per month.
I think it's easier for people to rationalise a simple cut of each sale rather than a fee for each "unique" installation. In the first case you can calculate that percentage easily in a spreadsheet and account for it in your business. In the second case it's totally unknown how to budget for. Should you assume 1, 2, 5 installs per purchase? How much of your revenue does that account for?
People would rather have a higher fee that is certain than a lower but uncertain fee (of course no fee would be best).
> So you believe a company can charge $99 for a yearly service and then say "by the way, we may increase prices in 30 days if we decide to do so." So what happens to the $99 I paid?
Uh, it would still be paid? Price increases only apply to new billing cycles, not retroactively, so I don't understand what you're getting at here.
The point is that it's incredibly easy — and relatively standard — to incorporate the possibility of changes into a contract.
If your pricing plans include an unbounded amount of anything, then the unbounded dimension will be abused by some proportion of your users. You will then be accused of a bait-and-switch when you try to correct your initial error.
You either need to charge for everything according to usage, place reasonable-and-transparent acceptable use limits on everything, or accept this dynamic.
Based on experience, I think your $8 plan will cannibalize your $22 a plan. The cold hard math of more private projects probably doesn't justify paying 150% more.
Because not all users use the same services in the same way, so that would actually lead to a mass breakdown in the services.
That's not how companies price services. Not by very, very, very far.
There are many pricing strategies designed to make heavy users pay more and light users pay less, or rich users pay more and poor users pay less.
Ideally, a company would charge a different price from every single user, and that price would be max(100% of the willingness to pay for that user, marginal cost of that user).
I don't know how many private repos I will be using in a year, so I pay for what I'm currently using. It may go up or down, and my plan will be adjusted accordingly.
If the problem isn't the on-my-credit-card-statement cost for the service that you'd use, and is instead a philosophical disagreement with how the cost is calculated... that's just a little bonkers.
reply