4 ms·

Ah, thanks for adding the other viewpoint! My rebuttal: 1. It may be money you're leaving on the table but you can't really say it's money you're earning. It's

by dreeves 13y ago

Ah, thanks for adding the other viewpoint! My rebuttal: 1. It may be money you're leaving on the table but you can't really say it's money you're earning. It's like a laziness tax on your users. (And, uh, not in a good way.) 2. Your point about cognitive overhead I think is quite backwards. The beauty of auto-canceling is that it's less cognitive overhead, other than the fact that it's unusual. (I hate it when "it's industry standard" is the excuse for not doing the right thing.) There was another Hacker News thread about pay-as-you-go vs tiered pricing: https://news.ycombinator.com/item?id=5664512 https://news.ycombinator.com/item?id=5664512 . I think the cognitive overhead of perennially re-evaluating whether you're getting your money's worth is a big reason developers like pay-as-you-go. And the biggest reason you wouldn't be getting your money's worth is that you're not using the service at all anymore. So I think auto-canceling subscriptions are the best of both worlds: simple and predictable, you can budget for it and think about it in terms of the value you're getting (an ongoing service) without the risk of paying for something you're not using. How's that not clear additional value?

svmegatron 13y ago
All good points, to be sure. I disagree about a standard "you need to cancel it" model of canceling being a laziness tax, but I can certainly see reasonable people disagreeing on that point. I should have explained my thinking on cognitive overhead a little more clearly - I think the overhead of explaining it at the beginning of the subscription is what could turn people away. No disagreement from me that once a user is signed up, they don't need to think about it as much. I certainly wish you the very best with this billing experiment, and will be excited to read the results if or when you choose to publish them!
- dreeves 13y ago
  I think the part that's the laziness tax is specifically the money being left on table -- from the business's point of view -- by using auto-canceling subscriptions. By definition that's money that you're collecting from someone despite them no longer using your service. For most services there's no possible explanation for that other than laziness (or something similar like cluelessness, or at best the user valuing their time too highly to think about it). In one way or another, the user is paying that money because they're not as on top of things as they mean to be. You can fix that for them with one line of code: charge(user, amt) unless last_active(user) < time() - 1.month You can get away with that charge and they technically/implicitly agreed to it, but, well, it's revenue that doesn't represent value you're creating. Imagine a friend/friend version of that business/consumer relationship. You would not keep taking your friend's money! Anyway, yeah, I think we're on the hook now to follow up on this in a few months or whenever we have enough data. :)

by dreeves 13y ago

svmegatron 13y ago

All good points, to be sure. I disagree about a standard "you need to cancel it" model of canceling being a laziness tax, but I can certainly see reasonable people disagreeing on that point. I should have explained my thinking on cognitive overhead a little more clearly - I think the overhead of explaining it at the beginning of the subscription is what could turn people away. No disagreement from me that once a user is signed up, they don't need to think about it as much. I certainly wish you the very best with this billing experiment, and will be excited to read the results if or when you choose to publish them!

dreeves 13y ago
I think the part that's the laziness tax is specifically the money being left on table -- from the business's point of view -- by using auto-canceling subscriptions. By definition that's money that you're collecting from someone despite them no longer using your service. For most services there's no possible explanation for that other than laziness (or something similar like cluelessness, or at best the user valuing their time too highly to think about it). In one way or another, the user is paying that money because they're not as on top of things as they mean to be. You can fix that for them with one line of code: charge(user, amt) unless last_active(user) < time() - 1.month You can get away with that charge and they technically/implicitly agreed to it, but, well, it's revenue that doesn't represent value you're creating. Imagine a friend/friend version of that business/consumer relationship. You would not keep taking your friend's money! Anyway, yeah, I think we're on the hook now to follow up on this in a few months or whenever we have enough data. :)