What Are Feature Flags? Everything Engineering Teams Need to Know

When Flagsmith’s other co-founder Kyle Johnson recently asked a room of ~120 developers if they use feature flags, only 40% of the hands went up. But in our experience, this number is actually much lower—sitting at roughly 20%.

This number is growing, though—and fast. As more engineering teams take on modernisation projects, feature flags play a natural supporting role for practices like trunk-based development, offering safety and agility with a relatively low barrier of entry. They also open the door to shorter development cycles and faster feature iteration by decoupling deployments from releases. More on that soon!

‍

If you’re wondering what feature flags are, and whether they could make sense for your team, in this guide, we’ll explore:

• The concept of feature flags
• How feature flags work
• When you should use them (and how other engineering teams are using them)

What is a feature flag?

Feature flags (also known as feature toggles, feature switches, or feature flippers) are if/else statements in the codebase that allow you to turn features on/off.

Think of feature flags as sophisticated light switches for your code. Just as a physical switch controls whether a light is on or off, a feature flag controls whether users can see or interact with a specific feature.

The implementation looks like this:

1. A conditional statement in your code that checks the state of the flag
2. A configuration system that stores the state of each flag (on/off)
3. An interface for changing flag states without modifying code

For example, in a banking application, a new funds transfer feature might be implemented behind a feature flag with code that looks something like this:

^{if (featureFlags.hasFeature('enhanced-transfer-feature')) {}

  ^{//code for the new enhanced transfer feature}

^{} else {}

  ^{//code for the existing transfer feature}

^}

What types of feature flags exist?

There are several types of feature flags, which are primarily categorised based on:

• The feature flag’s timespan
• The feature flag’s purpose
• The feature flag’s scope

Short-lived feature flags

You can use short-lived flags to act as temporary controls that last a single release cycle. The goal is to integrate new code into the main codebase while keeping it inactive until release.

For example, you can use a feature toggle if you want to hide a new transaction feature during testing. When you’re done testing, switch it off and release it to all users.

Long-lived feature flags

Long-lived feature flags remain in the codebase for extended periods—or permanently. They’re great in cases where you need:

• Kill switches
• Permission flags
• Support for multitenant architectures

You need to be careful and ensure they aren’t removed since they’re critical to the stability or usability of your application.

User-based feature flags

User-based feature flags control feature visibility based on user attributes or segments. Let’s say you’re releasing a new tax filing feature in a government portal. You can release it to only small business users or sole proprietors before releasing it to your entire user base to minimise risk.

System-based feature flags

System-based feature flags control functionality based on technical or environmental factors—not user attributes. They work well in cases where you use different deployment environments or system conditions.

For example, a finance app could use these flags to deploy region-specific compliance features based on the server’s geographic location.

Release flags

You can use release flags to control the deployment of new features to production environments. They allow teams to deploy and activate code separately, ultimately reducing the risk associated with new releases.

For instance, you can use it to gradually roll out certain features automatically when they hit certain thresholds.

Experimentation flags

If you’re running A/B tests or any experiment in your application, you’ll be using experimentation flags. They’re meant to help you measure the impact of specific changes you make. As a result, you can make better decisions about which combination of variables works better for your user base.

Let’s say you want to understand which button colours increase clickthrough rates in your app. You can run two or three versions of the button colour and analyse which ones drive the most action.

Operational flags

Operational flags manage system behaviour during runtime. So, they serve as an emergency control or a way to optimise performance in real time. If you run into production issues, these flags let you respond without redeployment or code changes.

For instance, if your app experiences high traffic, you can add thresholds to switch off certain functions to reduce the traffic burden on the app.

Permission flags

Permission flags control access to features based on user authorisation levels. They’re excellent for industries where you need to manage data access strictly or even gate features based on subscription tiers.

What are the use cases for feature flags?

Now that you know what kind of feature toggles exist, let’s look at how you can use feature toggles: 

1. Decoupling deploy and release

The most fundamental use case, and the foundation that most teams use as they get started with feature flags? Separating the deployment of code from the release of features to users. This process changes the software delivery process—allowing you to deploy code as it’s finished while having full control over when users experience a feature.

For example, a healthcare records system might deploy a new patient data visualisation component to production servers on Monday. But they could keep it hidden behind a feature flag. Their QA team can test the component in the actual production environment without exposing it to real users. Once they know it works, they can release it. And if something goes wrong, they can roll it back by turning off the flag.

2. Testing in production

You will never be able to fully replicate your production environment’s complexities. That’s the reality of testing today—especially if you have a microservice architecture.

In this case, you can use feature flags to “dark launch” new code paths executed in production, but the output is only visible to internal testers. This way, you can get real-world performance data and identify potential issues before they become problematic.

3. Progressive delivery

Progressive delivery takes the concept of continuous delivery a step further. You can gradually release features to a larger user segment while monitoring performance at each stage. You can use this to implement releases like:

• Canary deployments (exposing a small percentage of users to a new feature)
• Ring-based deployments (gradually expanding to wider user circles)
• Targeted releases to specific user segments

If you’re in a regulated industry, you can use this approach to catch issues with compliance or usability before it costs your business time and money to fix them.

Clip from Episode #49, Dynatrace - How OpenFeature Started

4. Lower risk in development

Risk mitigation is key if you’re in a regulated industry. That’s why even legacy institutions are slowly moving to feature flags as they create safety valves that allow you to respond quickly.

Here are a few ways to use them:

• Kill switches: Immediate deactivation of problematic features when issues are detected, without requiring code changes or redeployments.
• Controlled rollbacks: Revert to previous implementations without deploying old code—and maintain system stability during incident response.
• Configuration-based circuit breakers: Automatically disable features based on system health metrics or error rates.
• Compliance safeguards: Quickly adapt to regulatory changes by enabling or disabling features to maintain compliance.

5. Experiment and segment users

One of the biggest benefits of feature flags is that they give fine-grained control over what you roll out and who you roll it out to. This means you can use it for testing cases like:

• A/B testing: Running controlled experiments by showing different versions of a feature to different user segments and measuring the outcomes.
• User segmentation: Targeting features to specific user groups based on attributes, behaviours, or needs.
• Beta programs: Providing early access to new features for selected users who opt into testing.
• Gradual feature exposure: Controlling the percentage of users who see a new feature, increasing as confidence builds.

6. Modernise your development process

Digital transformation is no longer optional. As a result, many organisations—especially data-sensitive enterprises—are facing pressure to deliver value faster while managing risk. But it’s hard to do that with the traditional software delivery model. That’s why many engineering teams choose to use feature flags to safely (and confidently) deploy features and experiment as part of their modernisation effort. 

From a 30,000-foot perspective, this is what it can look like to modernise your development process, and where feature flags fit into this.

‍

Here are a few benefits you can experience:

• Faster recovery and resilience: You can reduce the mean time to recovery (MTTR) when incidents happen by enabling immediate feature toggles without emergency deployments.
• Accelerated innovation cycles: You can break large, risky changes into smaller, controlled releases that can be validated incrementally. And even run tests with shorter feedback loops more easily.
• DevOps transformation: You can bridge the gap between development and operations by providing shared tools for controlling feature availability (using role-based access).
• Continuous delivery adoption: You can enable frequent deployments without constant user-visible changes. As a result, you don’t have to deal with lengthy approval cycles and manually monitor rollbacks/changes.

Who uses feature flags and how do they use them?

These toggles are no longer meant for technical teams only. These days, feature flags are so simple to toggle on or off that even non-technical teams like marketing and customer success teams can use them.

Here’s how different teams within your organisations can use them:

• Developers: These teams are the main users (and caretakers) of feature flags. They integrate flags into the codebase while managing its cleanup and management process. For instance, once the flags no longer serve a purpose, they’re responsible for archiving them.
• Operations and DevOps: These teams are usually responsible for the production infrastructure and need feature flags to respond to incidents immediately. This means they handle processes like progressive rollout management, performance optimisation, and incident response.
• Product managers: PMs generally won’t modify the code directly but use feature flags to get as close to users as possible. For instance, they might roll out a feature and monitor usage/performance, then use that data to ask more pointed questions about how users like the functionality. Using that information, they’ll iterate and improve the feature.
• Marketing and customer success: These teams don’t get into the weeds of feature flag implementation. They’re more concerned with aligning their campaigns with feature rollouts or running more personalised experiences within the app.
• Security and compliance: While these teams might disable or enable features due to changing regulatory environments, they’re more concerned with the audit trails of your rollouts and risk mitigation.

How do you implement feature flags into your development process?

If you’re using feature flags, consider how they impact the entire software development cycle. Since feature flags impact how you build, test, and release software, you must be intentional about the process.

Here’s how feature flags work in the typical development environment:

• Development teams identify which features need flags and what kinds of flags to use.
• They implement these flags using standard naming conventions and documentation.
• As the code moves through the CI/CD pipeline, the flags are inactive—which lets you test without complete exposure.
• QA teams can also test flagged features in production within test accounts.
• When they green light the feature, developers or product teams activate the flags for specific segments.
• After they’re done testing and getting feedback, they can archive the flag (unless it’s a long-lived flag/kill switch).

As you begin to implement feature flags into your development practices, you may notice some common bottlenecks get easier to handle. Here are some typical reasons releases get pushed back and how feature flags prevent them:

What cultural and mindset shifts do you need to consider before implementing feature flags?

If you’re implementing feature flags, you need to think about it from a sociotechnical perspective. This means shifting how teams think about software development, collaboration, and release management.

It’s not just about adding conditional statements to your code—but changing how you collaborate with other teams. It’s about the little things.

As our customer success engineer Rodrigo López Dato puts it, “Feature flags are more of a social innovation than a technical one. Remember the other people who will be using the feature flag platform. When you name a feature flag, take the time to think of a good name. Make sure to add a description so people understand what happens when a flag is turned on/off. Be mindful of the people that will be using feature flags.”

As a result, developers need to ask questions like:

• Other than me, who will interact with this flag?
• What information will they need to make informed decisions about toggling it?
• How can I make the purpose and impact of this flag immediately clear?

This will result in better naming conventions, better descriptions, and clearer documentation. You won’t use a cryptic name like “ffnewalgo”—instead, you’ll name the flag “frauddetectionSMB.”

Our co-founder Ben Rometsch likes to say that you need to look at feature flags as “first-class citizens.” 

“See flags as first-class citizens on the same level as an issue or a pull request and make them part of your everyday routine and workflow. That helps integrate them into your day-to-day life. This lets you roll back features if there’s a problem once it’s gone live, or to test it with QA engineers or see how beta testers are finding them.”

Here’s what that would look like in practice:

• Introducing documentation around feature flags
• Reviewing a flag’s name and usage during code reviews
• Analysing flag behaviour during quality assessments (QA)
• Conducting retrospectives on flag usage and lifecycle management

Once you start seeing feature flags as a critical part of your development process, it’ll change how you deliver features over time.

When should you use feature flags?

We’ve addressed the implementation process—but just because you can wrap every feature in a flag, doesn’t mean you should.

Here are some scenarios where feature toggles will make sense and make an impact:

If you’re doing progressive rollouts

You don’t need to sit and manually roll out features to your entire user base. Instead, with feature flags, you can first release new functionality to a small percentage of users, maybe 1% to 5%. As you get more user feedback, you can rectify issues, make improvements and roll it out gradually to 10%, 25%, 50%, and eventually 100% of users.

If you’re testing in production

You can use flags to deploy new code to production but only enable it for:

• Internal testers
• QA specialists
• Test accounts

This way, you can test the functionality in a real production environment with real data, actual system loads, and integrations.

If you’re running A/B tests

Instead of creating separate documents for each testing variant, you can add multiple approaches in a single codebase. As a result, you can control exposure through feature flags.

Also, you can randomly assign users to different variants. This makes sure your comparison is statistically valid—and accurate.

If you’re beta testing features

Beta testing gives select users early access to new features. But this also requires precise control over who can use this functionality—which is where flags come in. You can create sophisticated beta programs by targeting users based on parameters like:

• Account type
• Usage patterns
• Opt-in permission

At the same time, the majority of your users continue with the usual version of your app—allowing for isolated testing.

If you want to rollout and rollback features faster

The typical development cycle requires days of reviews to roll out features. But with feature flags, you can deploy them without thinking twice. If your users experience any issues after activation, all you have to do is switch off the toggle—which immediately turns the feature off.

If you’re releasing code in coordination with multiple teams

Many engineering teams tend to work with other software teams or non-technical teams like marketing to release features. Feature flags simplify this by decoupling deployments from releases. Multiple teams can synchronise feature releases without needing to synchronise their deployment schedules. 

Best practices for using feature flags

When you’re implementing this technique into your software delivery process, make sure you stick to these feature flag best practices:

1. Use clear naming conventions: When multiple teams interact with flags, you can’t use ambiguous names as it’ll lead to confusion and misuse. Instead, figure out a standard naming convention that every team has to use—to avoid expensive mistakes.

2. Keep your codebase clean: Feature flag debt accumulates fast when you don’t remove flags after use. Over time, these flags remain in your codebase, increasing technical debt and interfering with your app’s performance.

“The biggest way to control how people use feature flags and enjoy using them is to clean up feature flags after ourselves,” explains Ben. “If you’ve created a bunch of feature flags for things you’re releasing and have released and tested, archive the old flags so you’re not polluting and confusing people and things are kept clean.”

3. Don’t reuse your flags: It’s tempting to use the same flag again and again. But if you don’t know the flag’s history, it’ll result in unnecessary side effects. In some cases, your app could crash completely, costing you thousands of dollars in revenue. You should create new ones, document their usage, and archive them when you’re done.

4. Highlight long-lived flags: In the same vein, every flag doesn’t need to be turned off when you’re done. Some flags act as kill switches or permission flags, which means you need to keep them on indefinitely. The best way to make sure no one touches it is to document its purpose and prevent access to the flag.

5. Use role-based access to prevent mishaps: Your feature flags shouldn’t be accessible to every team member because they directly impact your app’s functioning. So, use role-based access (RBAC) to assign roles and permissions based on your internal guidelines. Ideally, your developers do this based on the user’s team and reason for access.

When should you not use feature flags?

There are several cases where you shouldn’t use feature flags. Some of them include the following:

1. If your features are too simple

It’s obvious that introducing feature flags means you’re adding more complexity to your codebase. This is why we recommend doing so only when it’s necessary. For example, changing a visual element (when you’re not experimenting) doesn’t require a feature flag. But if you need to present information in different ways to different audiences, that might justify the use of one.

2. If your application’s traffic is too low

You need sufficient traffic to actually justify experimenting with using feature flags. If you have a very small user base, that wouldn’t help you run statistically significant tests, and there’s no point in using flags.

3. If you don’t have clear processes to handle flags

Flag implementation is a sociotechnical problem. This means you can’t just use them one time and call it a day. You need to have clear processes around:

• Who uses the feature flag
• Who can see the results of the test
• What specific user roles can do with flags

Don’t use feature flags if you don’t have the time or have a very small team size where you can’t justify this time/resource investment.

4. If you don’t have systems in place to remove flags

The most common antipattern is when engineering teams use feature flags but don’t remove them. Old, forgotten flags keep floating in your codebase while your technical debt increases. If you don’t have the right systems or can’t invest time, these flags will cause more harm than good.

5. If you’re using feature flags to replace business logic

Your flags shouldn’t replace business logic. Access control is one example of a case where you should avoid this. Let’s say you’re using a flag to guard your data and segregate between different types of users — but it’s left up to interpretation, your team might make mistakes. Your entire codebase will include flag checks making it hard to understand the true nature of the flag (and feature).

Do you need feature flag software?

If we’re being completely honest, solo developers rarely need a dedicated feature flagging tool. They can probably handle the conditional statements on their own—without the whole kit and caboodle. But if you’re a much larger team? It’s an absolute must.

Here are a few factors to consider if you’re in two minds about using a dedicated solution for feature flags:

Engineering team size

Small teams with just a couple engineers can often manage feature flags through simple homegrown solutions or basic configuration files. However, as your team gets bigger, this process becomes complicated.

Over time, you’ll see duplicate or conflicting flags in your codebase. This is where a feature flag software can help.

Application architecture

If you’re using a monolithic architecture, it's straightforward to share the feature flag across all of your application's components. However, with microservices, this process becomes challenging. Since your architecture is distributed across multiple services, you need a central solution to manage all your feature flags.

Development bottlenecks

If you’re constantly running into issues like QA capacity limitations, fixed deployment windows, or lengthy approval processes, feature flags could make your life a lot easier by separating deploy and release, adding agility to your testing processes and lowering the stakes of releases.

Security and governance

If you need more control over who accesses features and how they work with them, consider using dedicated flag software. Homegrown solutions don’t give you security controls like:

• RBAC
• Approval workflows
• Audit logging
• Compliance reporting
• Change requests

Unless you want to devote a whole lot of additional dev time to building these capabilities. You can avoid the hassle by using a purpose-built solution.

Open standards

Vendor lock-in is a massive concern for any company these days. If you plan on using a feature flagging solution, look for one that supports OpenFeature.

OpenFeature is an open standard for feature flags, backed by Linux—and it’s community-driven. If you choose a solution that offers this integration, you can switch providers without worrying about locked contracts.

Check out our interactive demo for more!

‍