Flip the Switch on Modern Software Development with Feature Flags

The Move to Modernisation: Where Do Feature Flags Fit In?

Romano Roth
Global Chief of DevOps at Zühlke 

‍

In my two decades of experience leading DevOps, Digital, and Agile transformations, I've observed that the path to modernisation is rarely a straight line. Organisations, particularly those in data-sensitive sectors, often find themselves at a crossroads. They need to innovate faster while maintaining rigorous security and reliability. This tension between speed and safety has traditionally forced companies to choose one over the other. But it doesn't have to be this way.

“Without feature flags, organisations struggle to separate deployment from release, limiting how frequently they can safely deploy changes.” 

Feature flags emerge as a strategic enabler in this journey, fundamentally transforming how organisations approach software development and delivery. They are essential for achieving high performance in modern software delivery, particularly in deployment frequency—one of the four key DORA metrics that indicate Software Delivery Performance. Without feature flags, organisations struggle to separate deployment from release, limiting how frequently they can safely deploy changes. With feature flags, teams can deploy smaller changes multiple times per day while maintaining precise control.

The ROI of Feature Flag Management

At a recent talk in London, our co-founder and lead front-end developer, Kyle asked a room of ~120 developers if they were using feature flags. Only about 40% raised their hands. This is pretty standard. Feature flags are a missing part of the equation for many companies.

But there’s an opportunity cost to this. Feature flags allow you to add a layer of security to your releases—while lightening the load of traditional deployment strategies. They allow you to reduce the risk of large-scale failures (as well as improve time-to-recovery) and become more agile, opening the door to greater innovation.

In this November 2024 survey of our enterprise customers, we wanted to get to the heart of what it looks like when companies open this door.

Feature Flags for Data-Sensitive Enterprises

Stability and predictability are two of the most important elements of building software. And when it comes to highly-regulated industries like banking, government, and healthcare this is even more pronounced. This can mean these organisations are slower to modernise, fearing change—and fearing risk.

But predictability can have a downside: if your company’s deployment practices are predictably slow and painful, you can block innovation and open yourself up to more risk, rather than less.

Feature flags, which work equally well in monolithic architecture or microservices and on the front end or back end of your software, can serve as a first step towards the holy grail of CI/CD, or simply as a way to de-risk your current large-scale releases. In the following chapters, we’ll explore key ways feature flags can help you on your modernisation journey. We’ll also share some first-hand accounts of how large companies in data-sensitive industries have used feature flags to modernise.

Removing Development Bottlenecks with Feature Flags

At first glance, a feature flag is just a Boolean that allows features to be turned on or off for individual users or groups without redeploying code. However, this simplicity belies the powerful ways feature flags can also help remove development bottlenecks, many of which stem from legacy systems that necessitate large-scale, infrequent releases and too many dependencies. 

Legacy systems can mean that engineering teams can’t release as often as they’d like, and they're stuck with monthly—or even quarterly releases. Enterprise releases are already high stakes, but if they’re also infrequent, they can end up as catch-alls, with the potential for error only increasing.

If a release gets pushed back because of a hard dependency, developers feel the strain. The next release gets bigger, there’s increased potential for issues, and it can end in a Hail Mary, which no one wants.

Feature Flags for Modern Releases

Using feature flags to de-risk releases

In software development, every new feature is a leap into the unknown and brings up questions like: will this work as intended, is it going to be well-received by the users, will it introduce new bugs? 

Feature flags form a shield against these uncertainties. 

Improve the safety of releases 

Risk mitigation is a critical part of software development. This was reinforced when, in a now-infamous incident, the cybersecurity company CrowdStrike brought the global business community to its knees with a flawed release that impacted PCs worldwide. In addition to wiping billions of dollars off the company’s market cap, it exposed the danger of foregoing modern release tactics. 

The crisis could have been avoided using feature flags really simply and easily via: 

Co-Founder Perspective

Feature Flags in Action: Working with Complex Applications and Large Development Teams

Ben Rometsch

Co-Founder of Flagsmith

‍

Lots of technical leaders see the potential benefit of flags, but want to understand where it would make sense to bring them in. I have this conversation a lot so wanted to share what I say to them:

Feature flags are generally easier to do when you deploy them on the front end of your application because you have “if this feature is enabled, show this button, menu item, tab, etc.” But it’s also very common for Flagsmith users to put feature flags into server-side applications. That’s where a lot of the power of flags comes in, especially if you’re working as part of a larger team. 

Decoupling deploy and release in microservices 

Imagine you’re running a microservice architecture, and you’ve got say 10 microservices. It can be difficult if there’s coupling between those microservices, for whatever reason, like API contract coupling, version coupling, coordinating the release of a large number of microservices, etc. this can be really challenging. 

Feature Flags for Migrations

Whether you’re planning a move from a monolithic architecture to microservices, merging two apps, or migrating users and components from a legacy system to a new one, feature flags can help with a smooth and gradual transition that reduces risk.

Migrating from a Monolithic Architecture to Microservices 

Moving from a monolith to a microservices-based architecture can be daunting. The stakes are high, and you don’t want to disrupt your platform stability or user experience during this massive undertaking.

Feature flags can give you much-needed flexibility as you make this move, helping you slowly migrate to microservices via phased rollouts. This reduces risk by letting you evaluate if the code works before you roll it out to all your users. And if something does go wrong, you can remotely roll it back without having to redeploy any code.

Merging Two Applications

When merging two apps, both the act of deleting old code and the act of adding new code is high risk. But if you keep your pull requests small and methodically merge your two code bases, you’re less likely to make mistakes. If, on the other hand, you take an all-or-nothing approach, with one massive pull request attempting to merge two applications together, the likelihood of human error will be high.

Feature flags allow you to work with small pull requests, iteratively rolling out changes while keeping feature flags turned off for users. This means all your work can go on behind the scenes, with nothing changing for your users until you want it to. As you introduce the new code, you can test it in production without your customers being impacted. This means when it comes time to make the switch, there’s no big scary release.

Getting Started with Feature Flag Management: 5 Best Practices

At a base level, feature flags are simple Booleans. So, even if your impulse might be to immediately jump into the most advanced feature flag use cases, we advise you to do the exact opposite. Start with simple use cases like kill switches, and as you see success you can gradually build your muscle memory until you’re ready to level up.

Start by using feature flags on very simple features that are isolated. Not only with the aim of technically getting used to feature flags but also getting the whole team, including non-technical stakeholders, to build confidence in this new way of working.

You can progressively get more and more advanced as your confidence builds. You’ll then naturally get to a point where you feel ready to start implementing them for more complex use cases.

With this in mind, we’ve brought together the most common best practices that help set teams up for success when starting with feature flags.

Why Feature Flag Management? Why Now?

Data-sensitive organisations are balancing two competing demands: maintaining stability and increasing agility. Feature flags let you do both. By de-risking releases and decoupling deployments from releases, you can introduce agility into your organisation without compromising stability. Development teams can move faster, collaborate better, and build stronger products—all while reducing risk.

For companies beginning or building on a modernisation motion, feature flags can help create a structure and way of working that paves the way for CI/CD and other modern development practices.