3 ms·

Oh my god I get a headache just thinking about all the feature flags they'll have to maintain, and all the copywriting to describe each feature, and all the sup

Oh my god I get a headache just thinking about all the feature flags they'll have to maintain, and all the copywriting to describe each feature, and all the support emails from people asking which features they can use... What are they going to do when a new feature makes another one obsolete? Keep both? What if they fix a bug in the new version, do they also fix it in the obsolete version? This sounds like a major maintenance chaos a few years down the line. They'll need to keep adding individual features to incentivise frequent re-purchases, so they'll end up with hundreds of variations of the app, all depending on when you bought it... Thinking about this makes me so happy about the pay-once model of my apps, I'm so grateful that it works, and that I don't need to squeeze every penny from my customers.

on_and_off 8y ago
>pay-once model of my apps it is a pity that people don't like subscriptions because it seems way more sane than fuelling development only with new customers. For some apps it works to pay once but if it is something that is constantly developed and/or has server costs, this is far from ideal
- jakobegger 8y ago
  As long as you make a decent app, there will always be new people that want it. And the larger your userbase, the more word of mouth advertisement you get. So it might not be the best idea to keep your userbase small by requiring them to pay again and again.
heckanoobs 8y ago
I think you can get by with adding timestamp support to a single feature flag. So the code has IS_PREMIUM everywhere but when you add a new use of it you also manually record the time. Since you know the expiration time of their license you can always determine what features are unlocked based on that. Then you just develop the app as any other demo-with-upsell app. Users even continue to get bug fixes and other updates after they let the license lapse. In cases where features are removed, combined, refactored, you'll have to be judicious about what timestamp you apply to the refactor. I would resolve in the customer's favor personally. Edit: Thinking on this more you might also want a rule like feature flags are only implemented at the view layer. That way your biz logic never gets tripped up on flag checks as features cross paths under the sheets. So its does require a fair amount of code discipline to pull this off
ropeadopepope 8y ago
> Oh my god I get a headache just thinking about all the feature flags they'll have to maintain Why not use a plugin model? Feature flags can be hacked.
- grok2 8y ago
  Making every feature a plugin is hard -- it requires that the original implementation expose everything possible in APIs to be take advantage of by a plug-in.

on_and_off 8y ago

>pay-once model of my apps it is a pity that people don't like subscriptions because it seems way more sane than fuelling development only with new customers. For some apps it works to pay once but if it is something that is constantly developed and/or has server costs, this is far from ideal

jakobegger 8y ago
As long as you make a decent app, there will always be new people that want it. And the larger your userbase, the more word of mouth advertisement you get. So it might not be the best idea to keep your userbase small by requiring them to pay again and again.

heckanoobs 8y ago

I think you can get by with adding timestamp support to a single feature flag. So the code has IS_PREMIUM everywhere but when you add a new use of it you also manually record the time. Since you know the expiration time of their license you can always determine what features are unlocked based on that. Then you just develop the app as any other demo-with-upsell app. Users even continue to get bug fixes and other updates after they let the license lapse. In cases where features are removed, combined, refactored, you'll have to be judicious about what timestamp you apply to the refactor. I would resolve in the customer's favor personally. Edit: Thinking on this more you might also want a rule like feature flags are only implemented at the view layer. That way your biz logic never gets tripped up on flag checks as features cross paths under the sheets. So its does require a fair amount of code discipline to pull this off

ropeadopepope 8y ago

> Oh my god I get a headache just thinking about all the feature flags they'll have to maintain Why not use a plugin model? Feature flags can be hacked.

grok2 8y ago
Making every feature a plugin is hard -- it requires that the original implementation expose everything possible in APIs to be take advantage of by a plug-in.