Skip to main content

The Salable Way

To get the most out of Salable, we have some recommendations around how to best set-up your plans and features on the platform.

The Basics​

The most common way to restrict access to a feature when developing an application is to check whether the current user has paid for a plan, and give them access if they have.

Let's imagine “Export CSV” is a “Pro” plan feature, you’d write some code to check whether the current user is subscribed to the Pro plan. If they are, allow access to the feature; if they aren’t, don't allow it.

This is a valid way to authorise access, and you can work this way with Salable, but it isn’t what we would recommend.

Embracing Granularity​

When working with Salable we would recommend taking a more granular approach to authorisation. What this means is, rather than checking what plan a grantee is on, check whether they have access to a feature.

This approach provides multiple benefits:

  1. If multiple plans give the grantee access to the same feature, your conditional code is simpler. You check against the feature name rather than having to compare against a list of many plans.
  2. You can easily change what features belong to which plans right from the Salable dashboard. This means your pricing model can easily be managed by non-developers and your application will automatically adapt to the changes. No code changes or deployments required.
  3. It enables the creation of bespoke plans which you can use to give the customer a custom combination of features.

Proprietary vs Bespoke plans​

When setting up plans, it’s helpful to think if they’re going to be proprietary plans or bespoke.

Proprietary plans are your typical "Basic" or "Pro" plans that customers can sign up for and contain pre-defined sets of features.

Bespoke plans are created for specific customers and grant access to a custom set of features.

When should I lock functionality behind the plan?​

As mentioned above, we wouldn’t recommend using the plan to authorise actions in your application. However, we do still return the plan name as part of the feature check data.

We do this to enable you to check against this value in specific cases where it can be helpful—such as when the functionality is inextricably tied to one specific plan.

If you're in doubt, then default to checking against feature values.

Summary​

So now you know the Salable way. As mentioned at the start of this guide, you can set things up however you see fit—but we believe the recommendations put forward in this guide will set you up for success and give you the best experience with the platform.

Now go and build something great.

The Salable Team