Feature flags, or feature toggles is a concept that has been around for a while but has not quite hit the mainstream adoption in every SaaS business just yet.
It is a common need to manage features based on different criteria such as authorization level, subscription tier, or grouping users for beta tests and A/B tests. Traditionally, this is handled by embedding control mechanisms directly into the code or configuration files.
However, in this article, we'll discuss how we transitioned from the code and config method to implementing feature flags. This shift allowed us to detache code releases from feature releases and have more precise control over features, Marking significant enhancement to our development process and autonomy to our Product owner, Sales and Customer success team.
Imagine you're a chef in a kitchen full of ingredients, but every new dish you want to try requires approval from a committee, a thorough kitchen clean-up, and a grand re-opening of your restaurant. Sounds stifling, right? Feature flags are like having a magical menu where you can instantly add or remove dishes based on what your guests are craving, without the committee and without the downtime.
In short feature flags makes it possible to toggle a feature without having to redeploy.
Feature flags can give a huge flexibility boost beyond the tech team. They allow for a more exploratory approach, enabling teams to test new ideas without the risk of a full rollout. This means more room for innovation and less fear of failure.
Feature flags are a powerful tool that can greatly enhance your DevOps processes, but their benefits extend far beyond that. One of the key advantages is the ability to decouple code releases from feature releases, which opens up a range of possibilities.
Feature experimentation becomes more accessible as you can safely test new features with live users without fully committing to a wide release. This allows for real-world feedback and data collection, helping teams iterate faster and make more informed decisions.
Another significant benefit is the ability to perform instant rollbacks or killswitching. If a feature is causing issues in production, you can quickly disable it without going through lengthy and complex rollback procedures. This minimizes the risk of downtime and ensures smoother operations.
Testing in production also becomes feasible with feature flags. Teams can deploy changes in live environments with more confidence, as they can control who sees the new features and monitor the results in real-time.
Finally, feature flags enable canary testing, where you gradually roll out new features to a small subset of users. This controlled release helps identify any potential issues before a full deployment, reducing the risk of widespread problems.
In our previous applications, feature control was straightforward; we used specific if statements directly in the code, like so:
if (Role == "Admin")
if (Subscription == Payment)
if (CONFIG_X == true)
This method seemed simple initially. However, when we wanted to incorporate beta features and A/B testing, things got a bit cumbersome. We had to identify beta testers, insert additional if statements, run the beta period, and then remove those statements afterward. Not only did this clutter the code with if statements, but it also necessitated adding extra parameters to user profiles.
As our applications expanded, accommodating new user roles and adjusting payment plans became frequent tasks and the pains started to creep up on us
We realized we needed more flexibility in managing our features, all without the need for constant releases
In our ideal scenario feature flags should make it possible to instantly rollout and rollback a feature. We also want the ability to dynamically link features to various attributes, such as user roles, geolocation, usage levels, or even random attributes for A/B testing. What if we could achieve this without requiring a new release each time?
To make this a reality, our first step is transitioning to incorporating feature flags or toggles in our code. However, the real challenge lies in ensuring that these feature flags can be enabled based on any parameter we define dynamically.
Instead of rigid conditions like if (Role == "Admin"), we aim to transition to a more flexible approach like:
if (Feature_X == UserShouldSeeFeature(ParametersThatDecideIfUserSeesFeature))
Where UserShouldSeeFeature() checks relevant attributes and returns either true or false.
Yet, as we delve into this transition, we realize the complexity involved. It becomes evident that creating such a system will require considerable effort, the daily pressure of delivering customer value overshadowed the long-term benefits of operational efficiency.
As it usually happens we could end up in the classic case of "we'll get to it later"
However, driven by our developer joy, curiosity and enthusiasm, we ultimately decided to take on the challenge.
We worked hard and went all the way and built an interface that worked seamlessly with our user management, subscription plans and RBAC. Now we could control features using all parameters that were attached to a user.
The immediate advantage of adopting the feature flag approach was the significant productivity boost it brought to our development process. We saw a reduction in the frequency of releases, eliminating the need to bundle numerous features together. By decoupling releases from feature deployments, we gained the ability to isolate and address bugs or errors without impacting the entire system.
This alleviated a considerable amount of pressure on our development team, particularly during release periods when we aimed to minimize the risk of production errors by scheduling releases during low usage windows, often during evenings and weekends, given our products' focus on B2B clientele. The ability to instantly roll out or rollback changes proved incredibly valuable in maintaining system stability.
Moreover, this approach yielded numerous benefits across various business areas:
Feature flags are not a new concept and we have known about it for a long time. But it took us some time to implement a feature flag management tool that could handle all the use cases we needed. It was difficult make this decision as we always balance between building features for our customers and making ourselves more productive. But it was definitely worth it. And we have made it accessible to everyone on nblocks
The inspiration came from Peter Hodgsons article on the subject and Martin Fowlers early article and after building 60+ SaaS apps we felt that we could build it in a great way that worked well for B2B and B2C cases.
If you wish to read more about best practices and uses cases have a look at our article that covers this in depth: Feature Flags Best Practices: The Complete Guide