Before you invest in feature flags

We end up explaining this on discovery calls often enough that it deserved writing down. Before you spend anything on feature flags, it is worth confirming a few things are already true.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

Prerequisites

• You can describe the outcome you want in one sentence
• Someone owns it after the work is done
• Flags let you ship code before you ship the feature
• You have a way to tell whether it worked

Warning signs

Rolling out to a small group first contains the blast radius. The reasoning matters more than the rule, because the rule has exceptions. Budget a little time for it every quarter and it never becomes a project of its own.

Delete flags once they are permanently on. The cost of getting this wrong is rarely visible on the day it happens. Assume whoever inherits this will have half your context and none of your patience.

In practice

The question is rarely whether something can be built, but what it costs to keep running afterwards. Three things worth confirming about feature flags before you move on:

• Someone can say what the current setup is without going to look
• Delete flags once they are permanently on — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If any of that sounds like a description of your current setup, it is fixable.