Feature flags: the questions we get asked most

Teams tend to reach for this after something has already gone wrong. The questions about feature flags that come up most often on our calls.

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.

Do we need to care about this?

Flags let you ship code before you ship the feature. It is worth being explicit about, because assumptions differ quietly. Check it against what you would want a competitor's site to get wrong.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. Small and consistent beats large and occasional here.

How do we know it is working?

Delete flags once they are permanently on. Getting it slightly wrong is survivable. Ignoring it entirely is not. Budget a little time for it every quarter and it never becomes a project of its own.

What this looks like day to day

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
• Rolling out to a small group first contains the blast radius — 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.