What are feature flags? Best practices and useful tips

Feature flags are a powerful software development technique that allow you to enable new features in your apps without having to distribute new code to all your customers.

This helps with many things, including testing features with selected users, gradual rollouts to see if key metrics change, and rolling back in case a bug is reported. 

This post explains what feature flags are, how they help you develop good software, and how to use them.

What are feature flags?

Typically, a feature flag is simply an on/off switch implemented in your code as a conditional statement that enables a specific feature when turned on. This might be something directly affecting the end user, like making a button visible in a new section of your mobile app, or it could be something more subtle, like integrating a new process or pipeline in the back end.

Because toggling the feature flag doesn't require a code update, you can deploy new features and turn them off if they aren't working as intended, or roll out and test new features in a staged manner. Your team can release software updates faster, maintain momentum, and revert changes in production if an app deployment goes awry. This is especially important if there's a delay between you pushing an update and users getting it, as with mobile app stores.

You may use feature flags in your code for a number of reasons, including:

• Testing the impact of new features and processes to make sure you aren't losing money or customers.

• Making features available at a certain time or to a subset of users.

• Reducing the risk associated with new technology rollouts or contractual obligations.

• Helping teams working across multiple time zones to release at their own cadence without blocking each other.

• Helping to reverse course if something doesn't work out.

Ultimately, feature flags are usually implemented by making use of simple logic in the application. Flags will reference an easily updated system or environment value, API, or service that most commonly provides a true/false value. For example, your app may check with your back end whether a feature should be enabled for a certain set of users by checking an API endpoint for a boolean value.

Some system designs will use more advanced flag mechanisms than simple On/Off, such as those which determine which route to send the user down, from a choice of more than just two. They still return a value to be consumed by the flag logic in a direct and manageable pattern.

What are feature flags used for?

Feature flags are commonly used in the following use cases:

Continuous integration/continuous delivery (CI/CD)

Feature flags can be used as a technical implementation of an embargo date. You can push your updates but keep features turned off until they are ready to go live. For example, suppose you want your frontend update rolling out while you finish work on the back end, or you're waiting for a big launch day event, or stakeholders insist updates be pushed to a certain schedule. A feature flag allows the code to go out and be switched on at a later date.

For distributed teams, feature flags can help you collaborate where time zones or project timelines differ: If one team is ready but another is not, the release manager of the dependent team can be given control of the flag and flip it when everything is ready to go live.

Personalised feature rollouts

Groups of users can be targeted by using feature flags to signal to your system which groups of users get to see a feature or set of content. For example, a feature in your app may be disallowed in certain regions due to privacy laws but allowed in others. A feature flag could target users in the first region to disable this feature without having to maintain separate code for both.

Deprecation

Feature flags can help remove functionality gracefully. When features are no longer needed, many teams simply remove their code, leading users to see sudden changes in an application or website’s presentation.

Non-technical team members can use feature flags to remove functionality gracefully by staging the removal of features before developers remove their code. This also allows them to be reinstated quickly if there are problems.

Feature flags can also be used to toggle removal notices and design changes gradually over time, and once the groundwork has been laid for the user and the relevant code is not in use, they can be removed.

Running A/B tests

A/B testing helps with targeting features to specific demographics for the purposes of testing. In this scenario, you would push an update that includes two variants of your application, applying an automated feature flag to different groups so you can see which update performs better. For example, you might have two variations of your user signup flow and want to see which one leads to more users joining your app. Once the best one is discovered, it can be rolled out globally, all without having to push new code. Of course, the flags won’t help you if you can’t see what the users prefer, so get your logging in to understand feature usage.

Controlled feature rollouts (with easy rollback)

Sometimes referred to as a kill switch, this is the ability to switch off a feature (or multiple features) with a feature flag. If an app update suddenly exhibits a dangerous flaw (like showing users private information about other users), you need the ability to roll back immediately. This might use a flag that affects many parts of the front and back ends all at once, or it might be as simple as leaving everything working while hiding the user interface component that gives access to the problematic feature.

Reducing stale branches (and maintenance headaches)

Feature flags help to avoid maintaining two codebases or release branches. Both versions of the code are deployed live, and only the features you want active are enabled. If a feature is not ready, you don’t need to keep it segregated away on a development branch — using feature flags, you can keep it merged into the codebase using version control and simply turn it off. This makes rebasing a thing of the past, and other developers on your team will really appreciate it. Just be sure that your developers are aware that multiple features are deployed at the same time, though this becomes second nature eventually.

Feature flags best practices

You can help drive faster, safer, and more flexible software releases by keeping these feature flag best practices in mind:

• Clear naming and separation of concerns: You should use clear naming in the code that implements flag logic, keeping the purpose of the variables and functions obvious and easily understood. You should also ensure dashboards that control the values have appropriate permissions to protect them from misuse.

• Signposting your flags: Be sure to make it clear in your code where you’ve placed a feature flag, and make this consistent throughout your code design and architecture. This starts with good naming and can extend to simple things like ALL CAPS names of the setting being referenced. Keep it simple and make it obvious — you’ll thank yourself later when it comes time to remove the flag code.

• Logging and analytics: As with any good monitoring, you should log the logic that manages your feature flags. This helps determine whether a flag is in use or hasn’t been changed in a while. Extend this not just to the implementation code, but also to where the flag setting is managed. This will highlight which flags have not been toggled in a long time and may need attention or removal. If you're using feature flags for A/B testing, ensure analytics are implemented so that you have full insights into the results of your experiments.

• Managing technical debt: When a flag is no longer required, remove the flag code as soon as its feature has been decided on and rolled out completely. Good project management should include time to deal with technical debt, which includes removing unused feature flags in a timely manner.

How not to use feature flags

While you can add feature flag logic anywhere in your codebase, depending on the functionality, you should make the boolean on/off value that acts as the switch itself high level and visible to all. The rule of thumb is do not bury it in code.

If you have the switch nested deep in a class hierarchy or namespace, or if it’s mired in the actual logic as a hard coded true/false “magic” value, then you need to bubble that right to the top without delay. Otherwise, developers will lose sight of the flags and might assume they are part of the logic, rather than a practical mechanism to control behavior.

Also, it’s a bad idea to place feature flags in config files (unless your hosting platform lets you update config files without redeploying). In order to flip a flag, you need to either re-deploy code, which is what you’re trying to avoid, or manually change the value, which amounts to coding it in production! Feature flags should be read from a service or provider, making the value of the flag usable and not a blocker.

Using feature flags to remove development roadblocks and align your team

Everyone involved in your development needs to be aware of feature flags that are implemented and in use. With that in mind, here are some perspectives for each team member’s role:

• Inform junior developers that flags are being used and tell them not to use or confuse the flag logic as part of the business logic when making changes. If flag logic is not indicated clearly, it can be all too easy for a developer — junior or otherwise — to miss the signs and use logic from one feature in another. 

• Make developers aware that feature flags are being used and ensure the developers do not erroneously remove them during refactoring or ignore them during code reviews.

• Inform your team that features may have been turned off and the code may or may not need to be cleaned up.

• Let the testers know about the multiple features within the code and which ones are enabled or disabled so they don’t create a list of bugs that don’t actually exist.

• Your project manager needs to keep track of features being handled by feature flags and plan for cleanup in the project life cycle.

Ignoring these responsibilities can lead to bloated and messy code, inefficient architecture, and version control headaches. Feature flags should make team life easier, but ignoring the code smell will make it harder.

Feature flags aren't the only way to experiment with new ways to impress your users

While feature flags are typically managed outside of a CMS, the Contentful content platform can manage the flag strategies above with Custom Flags, thereby supporting your workflows. When building modern, headless, CMS-driven applications, it’s important to have tools that support environment separation and real-time updates.

With multiple environments, live preview, webhook support, and our standout feature Custom Flags, Contentful enables teams to test content variations before publishing and react to changes. You can take the development concepts and strategies of A/B experimentation and feature flags and bake it into your Content workflows, with added AI insights into engagement, to find out what really speaks to your audience.

Start building

Sign up for a free Contentful account

Use your favorite tech stack, language, and framework of your choice.

Subscribe for updates

Build better digital experiences with Contentful updates direct to your inbox.