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 using feature flags. This shift allowed us to have more precise control over features, Marking significant enhancement to our development process and autonomy to our Product owner, Sales and Customer success team.

How we used to manage our features

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 tried to minimize the number of release by pushing many features at once
• The Testing Bottleneck: Each new release triggered a full-blown regression test, devouring resources that could have been used elsewhere.
• Every Customization Became a Project: Without feature flags, each customer-specific requirement turned into a development project, complete with its own release cycle.
• Tech Department Traffic Jam: Simple requests bottlenecked at the tech department, unable to be handled directly by customer success.
• Opportunities Missed: The lack of flexibility meant turning away clients with complex requirements that we couldn't efficiently implement or maintain.

We realized we needed more flexibility in managing our features, all without the need for constant releases

What are feature flags

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.

Using feature flags to get a better feature control

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.

Using feature flags to get a next gen Feature Control.

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:

• Product owners gained autonomy in decision-making related to features, beta testing, and personalizing experiences, while also having the flexibility to time releases in alignment with sales and marketing activities.
• Customer success teams could efficiently manage specific roles and features for VIP enterprise clients.
• Sales teams were empowered to customize pricing packages and tailor them to suit the needs of larger clients.

Feature flags, worth the effort

Feature flags are not a new concept and we have known about it for a long time.

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.

You can try it out by signing up at nblocks.dev

‍