I love tarsnap's usage-based pricing, but I think it only works because there's exactly one metric that they're using to charge me (bytes stored per time). If

I love tarsnap's usage-based pricing, but I think it only works because there's exactly one metric that they're using to charge me (bytes stored per time). If you're trying to charge for a service or set of services but your costs vary depending on your customers' mix of usage (imagine you're hosting files, and customers pay you both for storing the files and also for ingress/egress), suddenly you either have a complicated pricing model ($X per byte-month stored, $Y per egress byte) or you have to simplify the model down to one metric, but this has its own problems. Say you simplify down to just charging for storage. A few customers are going to figure out that you have "free" ingress/egress and they're going to use your service as a CDN that's cheaper than any other CDN, and now your costs are misaligned with what you're charging. Or if you decide to just charge for ingress/egress but not for bytes stored, a few customers are going to figure out that you're a "free" AWS S3 Glacier service and again your costs are misaligned with what you're charging. You can write a ToS that prohibits this and you can track down these users, but now you're engaging in adversarial behavior. I agree with the author that it's best to charge based solely on usage with a pricing model that isn't too complicated, but if your service isn't amenable to a simple pricing model, the next best thing is enterprise pricing -- because you want to find customers who are going to be price- / billing- insensitive, who need your service.