
## What is Feature Management?

<Link href="https://launchdarkly.com/feature-management/" children="Feature management" /> is an umbrella term for the tools and techniques adopted
by software engineering teams to build, experiment and release features in a controlled manner.

At the core of feature management, is the concept of a feature flag.

A feature flag in is simplest form, is an `if-else` statement, gating the execution of a freshly written block of code. The feature flag is typically toggled on or off via a UI.

The canonical use-case of a feature flag is to decouple code deployments from feature releases. They become a powerful tool for controlled releases when practiced with A/B testing and experimentation, during which the flag’s underlying logic causes a specified proportion of executions to take the `if-clause`, while the rest goes down the `else-clause`.

This allows a product manager (PM) to incrementally roll out a feature, while monitoring key metrics for statistical significance. He or she then makes a data driven call on whether a feature will fulfil its raison d'être and justifies a full release.

## Feature Flags vs Entitlements

An entitlement refers to the right to use a feature. In the context of a plan-based SaaS application, it is essentially whether Bob on Plan A can use Feature X. Entitlements are used to define the features each plan can access.

One way to implement customer entitlements is through the use of role-based access control (RBAC). Through RBAC, a user is assigned a role and assuming the role grants him or her a specific set of permissions. In the SaaS context, a user is assigned to a plan (role). The plan entitles him or her to a specific set of features (permissions).

While feature flags and entitlements are orthogonal concepts, feature flags can be used to <Link href="https://www.split.io/blog/feature-flags-entitlements/" children="streamline" /> the implementation of entitlements, resulting in cleaner code.

Managing entitlements through feature flags allows your business to unlock additional value for customers as well as minimize risk.

## Using Feature Flags for Entitlements

How do we <Link href="https://launchdarkly.com/blog/how-to-manage-entitlements-with-feature-flags/" children="structure" /> a feature flag for entitlements?

While most feature flags are boolean flags (a feature is either on or off) some tools allow you to have more than two variations, with types such as strings, numbers or JSON.

For example, LaunchDarkly allows you to add JSON variations to your feature flag. You can then encode additional metadata within the JSON variations which you can then parse and use in your control flow logic.

Can we get there with LaunchDarkly’s flag variations? Here is some pseudo-code using LaunchDarkly’s SDK:

<Code
  code={
    "client.on('ready', () => {\r\n  const flagValue = client.variation('YOUR_FEATURE_KEY', {});\r\n  const flagMeta = JSON.parse(flagValue);\r\n\r\n  // Retrieve the list of plans for the feature\r\n  const { planIds } = flagMeta;\r\n  // TODO: Retrieve current user plan\r\n  // TODO: Check if current user plan is in the list of plans\r\n});"
  }
/>

<br />
Encoding a list of plans that entitles customers to this feature is a naive but unscalable approach.

In terms of feature flag implementation, we will need to retrieve a customer’s plan and compare that to the list of plans in the feature’s metadata. This isn’t too difficult but involves
round trips to the feature flag service as well as your own backend to retrieve the relevant data.

More often than not, your pricing plans will be in a <Link href="https://www.heavybit.com/library/blog/optimize-pricing-and-packaging-feature-flags/" children="constant state of change" />. When you release new features, you need to decide which plans can access it. You may suddenly decide to let all users have access to a feature to keep up with the competition. You may want to carve out a limited time deal with a standalone set of features. Or grant a specific customer more usage of a feature as gesture of goodwill.

Coming from the angle of the product manager or sales team responsible for adjusting packaging, having to navigate a developer-first UI centered around features and updating `planIds` one by one is cumbersome, and simply a poor use of time.

Moreover, entitlements are merely the tip of the iceberg.

## SaaS Feature Management, Build or Buy?

A more complete solution for SaaS applications should include:

- • First-class support for Plans. A single source of truth so that Sales, Marketing, Customer Service and Product Management all know about the features included in each plan and are making decisions off the same data.
- • The ability to define a usage limit on a feature and evaluate if a customer’s current usage is within limits
- • The ability to set daily, weekly or monthly quotas on usage
- • The ability to track usage of a feature on a customer-level (LaunchDarkly only tracks flag evaluations)
- • The ability to continuously measure the results of price and packaging changes and flexibly change them
- • The ability for PMs or Sales to easily generate customized packages for a client eg. for Enterprise sales

As all this logic is probably going to be the same for every SaaS you build, there's immense value in abstracting it into a general-purpose framework.

You could <Link href="https://www.flagship.io/feature-flag-implementation/" children="build the solution" /> yourself, and many makers have indeed done so. But if you would rather focus on your core product, here's where Limiter comes in.

<Link href="https://www.applimiter.com/" children="Limiter" /> is a one-stop solution centered around feature management for SaaS applications.
It supports plan management, entitlement systems, limits & quotas, as well as the monitoring tools to measure the effectiveness of any pricing
and packaging changes — all the plumbing that you need to support your SaaS subscription pricing models.



If you are running a subscription-based SaaS the first order of business will be to integrate with a payments platform like Stripe or Paddle. This is when you will set up your pricing plans on their platform according to your pricing table.

![Limiter’s pricing table](/posts/1/limiter-price.png)

Back in your SaaS app, you will sync those same pricing plans back and associate each plan with features. In a relational database setting, this means creating the following tables at the minimum.

**users**: Users who have signed up for your app.

**subscriptions**: Subscription records synced from your payments provider. Each record contains references to a `Plan` and a `User`.

**plans**: Plan records synced from your payments provider. Each record contains an external reference to the plan on your payments provider.

**features**: These are features of your app such as Seats, Projects, Email Notifications etc.

**plan_features**: This is used to express a many-to-many relationship between plans and features.

But hang on, how do you deal with what a user is allowed to do on your SaaS app?

How do you ensure that email notifications won’t be sent for Alice on the ‘Hobby’ plan? Or that Bob on the ‘Team’ plan doesn’t create more than 10 projects?

This is when feature toggles and usage limits come into the fray.

## Types of SaaS features

Let's introduce three kinds of features commonly found in SaaS apps.

**Boolean**: These are your standard feature flags. They denote whether a feature is on or off. Eg. you can send out email notifications.

**Limit**: An absolute limit is set on the usage of a feature. Eg. you can only create 10 projects.

**Quota**: These are limits in which usage is reset on a periodic basis eg. you can sync insights up to 100 times a day.

## Managing usage limits and quotas

Oh but couldn’t I use a feature flagging platform to handle this? Well, yes and no.

A feature flagging and <Link href="https://launchdarkly.com/features/experimentation/" children="experimentation" /> tool like LaunchDarkly gives you the ability to gate features, and through <Link href="https://docs.launchdarkly.com/home/flags/variations" children="variations" /> you can even store metadata like integers or JSON to be returned alongside the feature’s state. However, the feature is still very much a boolean — it is either enabled or disabled. You will still have to write code to determine if a user has exceeded their limits or not, decide whether to store usage events, or keep a running count per user.

Hence, we’ll need a solution which unifies feature flagging, usage tracking and policy evaluation in order to bridge the gap.

Essentially it boils down to addressing these subproblems.

**Problem 1:** We need to check if a `User` can access a `Feature`.

**Solution:** Three-way join on the database, cache the lookup or encode the relationships into an RBAC [framework](https://casbin.org/) for efficiency.

**Problem 2:** We need to keep a count of the number of times a `User` uses a `Feature`.

**Solution:** Store the counts somewhere, preferably a database with fast read-write speed, strong consistency and atomic increment / decrement operations. A RDBMS or Redis comes to mind here.

**Problem 3:** We need to check if a `User` has exceeded limits on a `Feature`.

**Solution:** Middleware / policies on the client and server that checks the `User`’s usage against the `Feature`’s limit value.

**Problem 4:** For quotas, we need to periodically reset the `User`’s usage count.

**Solution:** Set up a Cronjob to reset usage at the desired intervals.

Now imagine that your pricing table looks like this:

![Shopify’s pricing table, truncated for brevity](/posts/1/shopify-price.png)

Modelling such a pricing matrix without having a framework for managing features and usage limits in a scalable, consistent and maintainable manner is a guaranteed recipe for disaster.

## System architecture

Here's an idea for a simplified system design that can meet all the above requirements.

![Limiter.jpg](/posts/1/limiter-arch.jpg)

At the core of this system design is the use of <Link href="https://aws.amazon.com/s3/" children="S3" /> as the persistence layer. While S3 is commonly thought of as an object store, it is in fact, a huge key-value store. Your data is stored in the form of blobs and accessed via keys i.e. the prefixes to your file. Moreover S3 comes with industry-leading scalability, data availability, security, and performance.

However the killer feature for S3 has got to be it’s <Link href="https://aws.amazon.com/blogs/aws/amazon-s3-update-strong-read-after-write-consistency/" children="strong read-after-write consistency" />. This means that it is perfectly suitable for keeping track of the usage counters mentioned above. It's essentially a cost-efficient, Redis alternative, albeit with lower read-write performance and a limited access patterns (list, set, put, delete).

With powerful tools such as <Link href="https://aws.amazon.com/athena" children="Athena" /> and <Link href="https://aws.amazon.com/glue" children="Glue" /> at your disposal, you can perform SQL queries directly on the data in S3 or set up ETL workflows to pipe it to a data warehouse.

The trade-off made here is the lost of querying flexibility, as compared to storing the data within the same RDBMS as the rest of your app.

## S3 data model

So what kind of data do we need to store on S3?

First is the feature matrix, which is a collections of plans and features and the attributes on these features.

<Code
  code={
    '{\r\n  "plans": [\r\n    {\r\n      "plan_id": "Hobby",\r\n      "features": [\r\n        {\r\n          "feature_id": "Seats",\r\n          "type": "Boolean",\r\n          "value": 1\r\n        },\r\n        {\r\n          "feature_id": "Projects",\r\n          "type": "Limit",\r\n          "value": 10\r\n        },\r\n        {\r\n          "feature_id": "SyncInsights",\r\n          "type": "Daily Limit",\r\n          "value": 100\r\n        },\r\n        {\r\n          "feature_id": "CustomerEmails",\r\n          "type": "Monthly Limit",\r\n          "value": 200\r\n        }\r\n      ]\r\n    }\r\n  ]\r\n}'
  }
  language="json"
/>

<br />
Secondly, for each user, we can store a map of features to usage counts. We can use the user ID as the object key to achieve O(1) lookups on
the S3 bucket.

<Code
  code={'{\r\n  "usage": {\r\n    "Seats": 5,\r\n    "Projects": 10,\r\n    "SyncInsights": 15,\r\n    "CustomerEmails": 20\r\n  }\r\n}'}
  language="json"
/>

<br />

You can then draw powerful insights from this data: which features do customers use the most or if a particular feature is being underutilized. This enables you to proactively reach out to your customers and course-correct before it's too late.
And that's all to it! A simplified usage limit and quota solution that can meet your SaaS product's operational needs.

## Should I DIY

At the beginning, hand rolling your own bespoke system for managing features and usage limits may seem like the obvious choice as it is deceptively simple. However, without designing for scale and maintainability from the get-go, tech debt will quickly skyrocket and you’ll find yourself staring down at a tangled mess of spaghetti code.

For solo founders, small teams and startups, who already have plenty on their plates, investing considerable effort to develop such a peripheral system might not be the best use of their time.

Try <Link href="https://www.applimiter.com" children="Limiter" /> today if you are looking for an out of the box usage limits and quota management solution that scales well with you, especially in the cost department.



## What is Tiered Pricing

Tiered pricing is a common pricing model for SaaS businesses. It works by offering multiple packages catering to different user groups. Each package, or tier, has its own price and range of features, possibly with varying usage limits.

<Link href="https://supabase.com/pricing" children="Supabase" /> is a great example of tiered pricing. It's Free and Pro plans have carefully
calibrated feature sets that cater to different personas.

![Supabase's pricing table](/posts/3/supabase-pricing.png)

## Why Tiered Pricing

Tiered pricing lets you capitalise on varying needs and budgets between different groups of consumers in order to sell each product as close as possible to the maximum price that each group is willing to pay.

With tiered pricing, you can flexibly target different user personas, ranging from end users to enterprise customers, while going as broad or fine grained as you like.

## How to Implement Tiered Pricing

Adding a tiered pricing model to your SaaS app is super simple with <Link href="https://www.applimiter.com" children="Limiter" />. It provides an opinionated framework from which you can manage plans and features in your SaaS app.

### Set up Products & Pricing

Let's configure a basic two-tier pricing for your app. We will go with a 'Basic' and a 'Pro' tier.

In this tutorial, we'll use <Link href="https://stripe.com/" children="Stripe" /> to bill customers for subscriptions.

On your Stripe dashboard, click on the **Products** tab and create the following products:

- • Basic, $5 / month
- • Pro, $15 / month

For first-time indie makers, consider leveraging this awesome SaaS subscription <Link href="https://github.com/vercel/nextjs-subscription-payments" children="boilerplate" />. It gives you a fully-usable app that comes with user management, Stripe subscription integration and even syncs your products from Stripe.

### Create Project

Create a project on Limiter with a name that best describes your current project.

![Project Example](/posts/3/project-example.png)

### Create Plans

Then, create plans which correspond to the products that you have created earlier on Stripe.

We will create the following plans on Limiter:

![Plans Example](/posts/3/plans-example.png)

### Create Features

For each plan, we can create features that you wish to gate or apply usage limits to. Limiter supports several feature types such as booleans, limits and quotas.

Assuming we are building a task management app and we wish to set a limit on the number of tasks a customer can create, we can create the `NumTasks` feature in the Basic and Pro plans with different limits:

![Feature Example](/posts/3/feature-example.png)

![Feature Example](/posts/3/feature-example-2.png)

### Gate Features with Feature Flags

A feature on Limiter is represented by a feature flag. Think of it as an if-else clause in your code that prevents a block of business logic from being executed unless certain conditions are fulfilled.

However, unlike typical feature flags whose primary concern is whether a feature is enabled or not, a Limiter feature flag also keeps track of whether the customer is entitled to the feature, and whether he or she has exceeded usage limits for that feature.

Now it's time to add the feature flag to your code.

Alongside each feature, Limiter provides a copyable code snippet so that you can easily integrate features flags with your app.

![Code Snippets](/posts/3/code-snippets.png)

Limiter provides flexible APIs to operate with the feature flags.

Here's the lowdown on some of them:

- • `feature`: Use this to check if your customer can access the feature
- • `increment`: Use this to increment a customer's usage of the feature by a fixed amount
- • `decrement`: Use this to decrement a customer's usage of the feature by a fixed amount
- • `set`: Use this to set a customer's usage of the feature to a specified amount

### Automatically Bind Customers to Plans

Head over to the Integrations page on your Limiter project and set up the Stripe subscriptions integration.

![Stripe Integration](/posts/3/stripe-integration.png)

You'll need to map your Limiter plans to your Stripe products and configure a Stripe webhook to send subscription lifecycle events to Limiter's backend.

Once enabled, Limiter will automatically bind your customers based on their Stripe customer IDs, to the corresponding plans on Limiter, the moment your customers have paid for a subscription or made any change to their existing subscriptions.

This binding is essential for Limiter to determine whether a customer is entitled to a particular feature.

## Conclusion

A tiered pricing model is easy to reason about and simple enough to implement given the right tools. Limiter is a one-stop shop for all your SaaS feature management needs which lets you implement tiered pricing in no time at all.


Blog

A Primer on SaaS Feature Management

How to manage features & usage limits in your SaaS app with S3

SaaS Pricing Tutorial: Tiered Pricing