# In Favor of Feature Toggles

The web is the best platform to deliver SaaS applications because it puts you in control of all aspects of your product. It allows you to release new features on-demand and without delay. You don’t depend on any third parties, and most importantly, you don’t have to wait for anyone’s approval (this problem is notorious in Apple’s AppStore). These are significant advantages, but you can benefit from this flexibility even more if you implement feature toggles in your product.

With feature toggles, you can control the availability of features in your product on a per-user basis. This definition is a bit abstract, so maybe it will be more tangible with a simple example.

Imagine you built a SaaS product with three features, and you are selling it in three different packages, where the available feature set depends on the user’s chosen package:

Package Small Medium Large
Features A A, B A, B, C
Price 10€/month 20€/month 30€/month

You can, of course, hard-code the knowledge about your three packages directly into your application. However, if you do this and later on want to change your pricing plans, you have to update your code. This is a waste of time and money, and perhaps even more importantly, very error-prone. Feature toggles like we advocate, solve both of these problems.

In effect, we make the knowledge about the availability of features for specific users part of the data, as opposed to the code. The information about enabled/disabled feature toggles lives in the database so that making changes boils down to updating just your database. Of course, it’s straightforward to build a simple UI to administrate the feature toggles if you don’t want to mess with your database directly.

Hard-coding has another considerable disadvantage: You lose the per-user granularity.

Building on the previous example, let’s assume you release a new feature X and decide to include it in your “Large” package. However, since X provides substantial additional value, you also increase the package’s price to 40€/month. Ok, new users can no longer buy “Large” without X. However, what are you doing about existing users who already bought “Large” for 30€/month before you released X?

Well, if you hard-coded your package information you have no choice. If you update your code to include X in “Large,” all users gain access to X - including existing users. That’s not good, because you don’t want to give away X for free. Ideally, you would like to approach existing users and upsell them on buying X for an extra 10€/month. This approach is no problem with the per-user feature toggles but would be messy without them.

There’s at least one other use case where feature toggles are handy. If you release a new feature, but you want to test it first, you can use feature toggles to expose it only to a subset (e.g., 1%, randomly selected) of your userbase. The point of doing this is to reduce the risk associated with releases. If your new feature is broken or receives negative feedback, you have time to fix it, before releasing it your whole userbase.