The missing ingredient is whom it is that's producing the software. If I wanted to be a solo developer, I would go with option 1 and simply charge as high a pr

The missing ingredient is whom it is that's producing the software. If I wanted to be a solo developer, I would go with option 1 and simply charge as high a price as I possibly can and still make enough profit. That way I have better quality customers and fewer of them to complain about things. If a feature is widely requested, my customer base already has demonstrated that they've reached financial "escape velocity" and may be willing to front the money to make new features happen. What I might do from the outset is split more distinct features into their own "add-ons" that can be paid for extra. That way, if a feature is needed but only applies to a fragment of my user base, only the people who want it will be charged for it. Subscription models are idealized because you can charge peanuts and rely on the fact that most people won't remember to cancel their subscription. I'm not much a fan of this model because the quality of user is lower and it turns every user into a customer all the time. A one time purchase, on the other hand, doesn't necessarily imply that support be provided indefinitely. From a technological perspective, managing subscriptions is a pain in the rear, whereas not a whole lot of code is needed to charge cards just a single time. You might need a license server, but I'd rather my license server be compromised than find a rogue for-loop charged my customer's credit cards a hundred times over.