Feature Flags in the Real World

Why do teams use feature flags? Because “move fast and break things” is only fun until you break prod. Feature flags let you move fast and break things slightly less dramatically. Here’s how real engineering teams actually use them. For more background, see Microsoft’s docs.

Canary Releases

A canary release means you roll out a change to a small percentage of users first — say, 1% — before exposing it to everyone. If the 1% starts screaming, you flip the flag off and investigate. If they don’t notice anything wrong, you gradually increase the rollout.

The name comes from the old mining practice of bringing a canary into a coal mine to detect toxic gases. Your early users are the canary. Hopefully, nothing explodes.

This pattern is especially valuable for high-traffic systems where even a small bug can affect thousands of users. Rolling out slowly gives you real production signal without betting the whole user base on it.

A/B Testing

A/B testing with feature flags means showing two different versions of a feature to different groups of users and measuring which performs better. Want to know if the green button converts better than the blue one? Wrap it in a flag, split your traffic, and let the data decide.

The flag controls group assignment. Your analytics platform measures the outcome. When the experiment concludes, you ship the winner and delete the flag. Simple in theory. Slightly painful in practice when the experiment runs for six months and everyone forgets what you were testing.

Kill Switches

Sometimes things go wrong in production. A third-party API starts returning garbage. A database query locks everything up. A new feature is causing unexplained memory leaks. You need to turn it off immediately, without rolling back a deployment or waking up the release manager.

Kill switches are ops-style feature flags that exist specifically for these moments. They’re always off by default and flipped on only in emergencies. With a kill switch in place, the on-call engineer can disable a problematic feature in seconds rather than scrambling through a deployment pipeline at 2am.

Beta Testing and Early Access

Feature flags let you give specific users early access to new functionality before it’s fully released. Power users, internal testers, customers on your beta program — anyone you trust to find bugs before the general public does.

This approach lets you collect real feedback on a real feature without committing to a full release. If the feedback is bad, you disable it for the beta group and go back to the drawing board. If the feedback is good, you roll it out to everyone. The flag controls access; your users do the testing.

Managing which users are in the beta group is a lot easier from a web UI than from a config file. A dedicated flag management tool handles this without making you write custom targeting logic for every new beta cohort. We'll cover one of those tools in a later post.

Dark Launches

A dark launch means you run new code in production but don’t show its output to users. You’re testing performance and correctness under real load without any user-visible change. The flag enables the code path; the results go to a log or metrics system instead of the UI.

Dark launches are particularly useful for risky backend changes — new database queries, algorithm replacements, infrastructure migrations. You get production-scale validation before you commit to the new implementation.

Use feature flags. Break things more safely. Look like a genius when nothing goes wrong.