So, to expand a bit on the concept of paid features, my current strategy, I give two options:
1) The paid feature, if it is based on a fixed fee, includes a warranty period, where we will prioritize fixing breaking changes as other parts of the codebase change.
Once the warranty period is expired, it required additional payments to fix the feature.
2) No warranty, but the feature cost increases their monthly or yearly SaaS fees, and requires advanced notice if disabling the feature.
As long as the user is paying for the feature, development resources will be devoted to maintaining it.
This also helps steer customers toward option 2.
Honestly, I use both these strategies more-so to prevent wasted time with feature requests the customer has no interest in paying for.
It forces them to find value in what they are asking for, not just because it is a ‘great idea’.
1) The paid feature, if it is based on a fixed fee, includes a warranty period, where we will prioritize fixing breaking changes as other parts of the codebase change.
Once the warranty period is expired, it required additional payments to fix the feature.
2) No warranty, but the feature cost increases their monthly or yearly SaaS fees, and requires advanced notice if disabling the feature.
As long as the user is paying for the feature, development resources will be devoted to maintaining it.
This also helps steer customers toward option 2.
Honestly, I use both these strategies more-so to prevent wasted time with feature requests the customer has no interest in paying for.
It forces them to find value in what they are asking for, not just because it is a ‘great idea’.