What is a feature flag?

Feature flags are one of the tricks that separate a mature development team from one that releases new features with crossed fingers. The term sounds technical, but the idea is everyday: a switch. Here’s what a feature flag is, what it’s used for, and why it’s worth knowing about even as a buyer.

The definition

A feature flag – sometimes called a feature toggle – is a switch built into the code that turns a feature on or off without needing to release a new version. The feature is already in place in the software, but the flag decides whether it’s visible and active or not.

That sounds simple, and it is. But the effect is big: it breaks the link between the code existing and the feature being on. Instead of a new feature inevitably going live the same second it’s released, the team can decide exactly when, for whom, and how fast it should roll out – and switch it off just as easily.

The three main uses

Feature flags are mainly used for three things, and all three reduce risk.

1. Gradual rollout. Instead of turning on a new feature for everyone at once, it’s released to a small share of users first. If everything looks good, it’s widened step by step. If problems show up, only a fraction has been affected, and the feature can be switched off before it reaches more people.
2. Testing with selected customers. A feature can be turned on just for a pilot group – a few selected customers or the company’s own staff – who get to try it live and give feedback before it opens up to everyone. You test in reality, but at a controlled scale.
3. Panic button for bugs. If a recently released feature turns out to misbehave, it can be switched off instantly with a click. You avoid rushing out an emergency fix and shipping new code under pressure – the feature is simply turned off until the bug is investigated calmly.

A concrete scenario

Say a payment service is adding a new payment method. The code is deployed, but behind a switched-off feature flag – no user sees anything yet. The team turns it on first for their own staff, who test the whole flow live. Everything works.

Then it’s turned on for five percent of customers. The numbers look good, and the share is increased step by step to everyone. Had something gone wrong along the way, the flag would have been switched off in a second, without panic and without a new release. Same feature, but rolled out with control at every step instead of one big, irreversible leap.

The difference between deploying and launching

That scenario shows perhaps the most important point: feature flags separate deployment from launch.

Deploying is putting the new code into the live environment. Launching is making the feature available to users. Without flags, it’s the same event – code out, feature live, at the same moment, often late at night to minimize the damage if something goes wrong. With flags, the code can be deployed switched off at any time, and the feature turned on later at a chosen moment. That makes every change calmer and less risky, which is a big part of the value.

The maintenance warning: clean up old flags

There’s a downside worth knowing about. Every feature flag is a branch in the code – an “if the flag is on, do this, otherwise that.” As long as the flag is needed, that’s fine. But once a feature is fully rolled out to everyone, the flag has served its purpose, and if it’s left in place it clutters up the code.

Many forgotten flags make the code harder to read and easier to get wrong in – a form of technical debt that builds up quietly. A responsible team therefore cleans up flags that have played their part, so only the active ones remain. It’s nothing to worry about, but it’s one of the things that separates disciplined development from sloppy. If you’d like a neutral opinion on how your system is managed on points like this, get in touch.