Getting started with feature flags
There is no clever trick in this one, just a handful of decisions worth making deliberately. A short on-ramp to feature flags for teams who have not touched it before.
The question is rarely whether something can be built, but what it costs to keep running afterwards. It is worth deciding this deliberately rather than inheriting whatever the last person set up.
Why it matters
Flags let you ship code before you ship the feature. It is worth being explicit about, because assumptions differ quietly. Doing this properly once is usually cheaper than doing it approximately three times.
Your first week
- Find out what is already in place
- Rolling out to a small group first contains the blast radius
- Change one thing and measure it
Delete flags once they are permanently on. There is a version of this that is over-engineered, and it is worth avoiding. The version that survives contact with a real deadline is the simple one.
What this looks like day to day
Most development decisions are really maintenance decisions wearing a different hat. Three things worth confirming about feature flags before you move on:
- Someone can say what the current setup is without going to look
- Flags let you ship code before you ship the feature — 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.