5 ms·
Restrict existing free application to a subscription model later on?
While trying to launch a mobile application I wonder how I should handle adding a payment solution later on. I would like to have all features available for free in the beginning to get as much feedback as possible. Once I have decided on which features to keep I would like to lock most of them behind a subscription solution. How do you handle this? Does existing users feel betrayed if they suddenly has to subscribe in order to keep using the app?
- brudgers 5y agoInstead charge money from the beginning. It will provide useful feedback regarding whether people will pay and if some people will pay, what they will pay for. You want people who are willing to pay. You don't want people who are unwilling. Requiring payment is basic market segmentation. Good luck.
- waspight 5y agoYou are probably right. As soon as the payment implementation is in place I will do that.
- jeffreygoesto 5y agoYes.
- usrbinbash 5y agoIf an app I was using did that, I would immediately delete it from my device and look for an alternative. It wouldn't even matter to me if the alternative offered less features.
- waspight 5y agoYes, that is what I was thinking as well. But how could it be solved? I mean, as an MVP it will be much faster to test features without having to implement payment first.
- usrbinbash 5y agoTesting is what Beta phases are for.
- beardyw 5y agoMy approach for a business solution was to limit volume on a fee account and let their growth tip into paid options. It was clear up front. Never modified it. YMMV
- throwawaynay 5y agoMaybe call it a free beta since you want feedback?
- waspight 5y agoYes, I am leaning towards that.
- toast0 5y agoDescribe it as paid, with a free year, and extend everyone's account periodically until you've figured out what to charge for (and how). When you do figure out what to charge for, consider charging long time users less, or extending them out one last time.