What is Feature Flagging?

Why the pattern exists

Without feature flags, a deploy and a release are the same event. Pushing code to production means making the change visible to everyone simultaneously, and rolling back means a hot deploy in the middle of an incident. Feature flags decouple the two. The code can sit in production for weeks, off by default, and be enabled for 1% of users, then 5%, then 50%, then everyone — or turned off in a second if the metrics go sideways. The pattern is what enables modern continuous delivery without the heartburn of "every Friday is risky."

The four kinds of flags

Pete Hodgson's 2017 taxonomy is the standard reference. Release toggles hide work-in-progress features from users until they are ready; they are short-lived and should be deleted after the rollout. Experiment toggles route different cohorts of users through different code paths so the team can measure which converts better. Ops toggles are kill switches that disable a feature, vendor integration, or expensive code path in a hurry — they tend to live forever and exist precisely so they can be flipped at 2am. Permission toggles gate paid features or beta access on a per-customer or per-plan basis and are essentially a part of the entitlement system.

Conflating the four is a common source of trouble. A flag built as a quick release toggle that grows into a permanent permission gate without anyone deciding it should becomes a long-tailed mess.

Where the debt accumulates

A feature flag is a fork in the code. Every flag doubles the number of paths through whatever it gates, and a system with fifty long-lived flags has 2^50 theoretical configurations, of which roughly four are actually tested. The cost shows up as bugs that only reproduce when an unusual combination of flags is enabled, and as code that no engineer can read confidently because there are six branches gated on six toggles. The fix is process: every release toggle has a removal ticket, and "did you delete the flag" is part of the rollout checklist.

Build vs buy

Hosted platforms — LaunchDarkly, Statsig, Flagsmith, ConfigCat, Unleash, PostHog — give you a UI for non-engineers, audit trails, targeted rollouts by cohort, and SDKs in every language. They are worth the cost the moment product managers want to flip flags themselves, or the moment the experiment count crosses ten or so. For smaller teams, a flags table in Postgres with a typed accessor in code is plenty — usually less than a day of work, and trivial to migrate to a hosted platform later.

At QUANT LAB

Every SaaS platform we ship has flag infrastructure on day one — even when the first feature behind a flag doesn't exist yet. The marginal cost of building it in early is hours; the marginal cost of retrofitting it during an incident is the incident. Most projects use a Postgres-backed flag system with an admin panel; the cost of LaunchDarkly stops being worth it for clients under a few thousand users.

Flags pair naturally with blue-green and canary deployments — the deployment infrastructure ships the code safely, the flags govern who sees it. Read our platform engineering guide for how this fits the broader rollout story, or book a call if you are planning a risky launch and want a sober review of your rollout plan.