Feature flags, explained without the jargon

Every audit we run turns up some version of this. Here is feature flags without the vocabulary that usually surrounds it.

The question is rarely whether something can be built, but what it costs to keep running afterwards. Assume whoever inherits this will have half your context and none of your patience.

The short version

Flags let you ship code before you ship the feature. There is a version of this that is over-engineered, and it is worth avoiding. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. It is worth being explicit about, because assumptions differ quietly.

Rolling out to a small group first contains the blast radius. Small and consistent beats large and occasional here. Write the reasoning down alongside the decision, because the reasoning is what changes first.

Making it stick

Delete flags once they are permanently on. Getting it slightly wrong is survivable. Ignoring it entirely is not. Check it against what you would want a competitor's site to get wrong.

How to tell if yours is fine

Code gets read far more often than it gets written, and usually by someone with less context than the author had. 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

The point is not perfection, it is knowing which of these you have consciously chosen to skip.