Feature Flag

When a development team builds a new feature into an app, that feature doesn’t have to be visible to everyone right away. Instead, it can be placed behind a switch. This switch is a feature flag: a spot in the program code that checks whether the new feature is currently allowed or not. If the switch is set to “off,” the app behaves as it did before. If it’s set to “on,” the new feature appears. The switch is flipped from outside, via a central setting, and it happens while the system is running.

Why big providers can no longer work without switches

In the past, software was released in large packages, often just a few times a year. Today, many companies ship new versions multiple times a day. This increases the risk that a change causes bugs. A feature flag separates two things that used to be tightly linked: shipping the code and releasing the feature to users. The code is already sitting on the servers, but nobody notices anything.

The practical benefit shows up in emergencies. If a new payment feature starts producing errors, nobody has to scramble to build a fixed version. One click resets the switch, and seconds later the old state is back. Without flags, such a rollback can, in a bad case, take hours.

Then there’s the business angle. Companies want to know whether a new feature actually delivers value before rolling it out everywhere. With a flag, you can turn the feature on for two percent of users and compare the numbers against the rest. This is called an A/B test: two groups, one difference, then a comparison of the results.

From switch to rule in the code

Technically, a feature flag is, in the simplest case, an if-check. The code asks: Is the “new search” feature active for this user? If yes, the new part of the program runs; if not, the old one does. The answer isn’t stored in the code itself but comes from a service that manages all of the company’s switches.

It gets interesting because the answer can differ from user to user. The rule might be: on for all employees, on for five percent of all remaining users, off for everyone else. This allows a feature to be rolled out in stages, first internally, then to a small test group, then to everyone. After each stage, teams watch whether error rates or load times get worse.

The typical mistake is to consider flags harmless. Conceptually, every switch doubles the number of possible states the software can be in. Ten flags theoretically produce over a thousand combinations, all of which would need to work. That’s why the rule is: a flag that has served its purpose gets removed, along with the old code. Forgotten flags are a well-known source of hard-to-explain bugs.

Feature flags in AI features and in company announcements

As a user, you usually only notice feature flags indirectly. A friend already has the new interface in the same app, but you don’t, even though you both have the same version installed. That’s exactly a flag at work. Announcements like “the feature will be rolled out over the coming weeks” describe nothing other than a switch being turned up gradually, step by step.

Flags play an especially big role with AI products. A new language model in a chat service is expensive to run and hard to predict in behavior. Providers therefore first enable it for a small group and compare response quality, cost, and complaints. If the results turn out poorly, the switch gets flipped back, often without the public ever noticing.

In financial and tech news, flags usually show up between the lines. When a company reports that a bug was “fixed within minutes,” there’s almost always a switch that got flipped back behind the scenes. And when an announced feature fails to appear for months, it’s often already sitting in the code, just switched off.