How do I design a Web app with different feature sets for different users based on subscription level?

Looking for some insight into architectural patterns for applications that have different feature sets enabled for different users based on their subscription.

I am not referring to roles - admin vs user vs manager - but rather how my entire available feature set or capacity might change based on my subscription.

Look at github or freshbooks or firebase or heroku as an example. There are multiple plans. The free plan A can only do X+Y, while paid plan B can do X+Y+Z (and have 10 more of them), paid plan C can do W+X+Y+Z (and have 100 of each).

Obviously, I don't want to bake these limits and features too tightly into code, or it takes a long time to build, and any change (moving features between plans, or limits on various features) becomes a nightmare.

What patterns are people using so that a user:

  • Is only able to use those features relevant to him/her
  • Is limited by the limits available to him/her
  • Has those limits/features automatically changed when a subscription level changes (up or down)
  • Sees upsell opportunities (shown features that are not available, but can be purchased)?

Looking for an architecture design here, examples welcome in Java, NodeJS, RoR, or PHP.

From a very high level perspective, I might start with the following:

  1. Make the "roles" (or whatever you want to call them) inclusive - not exclusive. Or additive rather than subtractive. It's easier to only show a/b/c than to show all by default, then try to lock down the restricted features.

  2. Have the API handle all of the logic for who can do what, so by the time the data gets to your views, it's already a limited set based on the user's available features.

  3. Access levels can be on a per user basis, or by some kind of named groups, which might make it easier to bulk upgrade users, etc.

  4. For a prototype, you might do the UX such that if the user requests a feature from the API they don't have access to, the API could send back a certain HTTP header/etc. and your front-end could show a generic "upgrade your account" message.

You're question is pretty broad.

One last thought - if you think the application would be large, it might be beneficial to create one base API, and then other APIs that inherit from that, each with specific features. Again, there are numerous ways to do this... node modules come to mind. That way you could create different experiences for each level of "plan" the user is on, but still reuse code.