What Are Feature Flags? A Practical Guide for 2026

A feature flag is a runtime switch. The code for a new checkout, a new pricing table, a new onboarding flow is already on your servers. The flag decides whether a given user actually sees it.

That sounds like an if statement, because it is one. The difference is where the boolean lives. Hardcoded in the repo, you need a deploy to flip it. Stored in a flag service and evaluated at request time, you can turn the feature off in seconds from a dashboard, an API, or a coding agent, without touching git.

If you have ever reverted a commit to undo a bad release, you already wanted feature flags. You just paid for the lesson the slow way.

Feature flags vs feature toggles vs remote config

Search results treat these as different products. They are mostly different names.

Feature flags and feature toggles are the same thing: an on/off (or percentage) decision at runtime. Martin Fowler's original feature toggle writeup is still the cleanest explanation of the idea.

Remote config is a flag that returns a value, not just a boolean. A theme, a copy string, a price. Same delivery path, richer payload.

A/B tests and experiments use flags to split traffic, then add a stats engine: sample size, p-values, CUPED, holdouts. If you only needed to ship safely, you do not need the physics lab.

I am building a flags-only product, Betterflag, so calibrate accordingly. Most teams that think they need "experimentation" needed a percentage rollout and a kill switch.

Deploying is not releasing

This is the distinction that makes feature flags worth adopting.

• Deploying is a technical event. Code is on production servers.
• Releasing is a product decision. A user can touch the feature.

Couple them and every merge is a bet you cannot unwind without a revert, a CI run, and a twenty-minute pipeline while production burns. Split them and the code can sit dormant behind a flag. You turn it on for yourself, then a beta list, then 10% of traffic, then everyone. If the error rate jumps, you turn it off. That is a kill switch, not a rollback.

const showV2 = await flags.isEnabled("checkout-v2", { userId: user.id });

return showV2 ? <CheckoutV2 /> : <Checkout />;

The new checkout is deployed. Nobody sees it until the flag says so.

The four primitives that actually matter

Enterprise flag platforms will sell you a targeting DSL, segments, multivariate experiments, approval workflows, and a forty-page getting-started guide. Most of your flag life is four operations:

1. On or off. A boolean that lives outside the deploy.
2. A percentage rollout. 10%, then 50%, then 100%. See percentage rollouts.
3. A little targeting. Plan, country, a beta cohort. Not a rules engine.
4. A kill switch. Faster than a deploy. See the kill switch pattern.

If a tool cannot do those four in five minutes, it is the wrong tool for the job you actually have. Everything else is real, and some of it is even good. It is also not why you adopt flags on day one.

How a feature flag is evaluated

At request time (or at the edge, before the request hits your origin) the SDK asks: given this flag key and this user context, what is the variation?

The context is usually a user id plus a handful of attributes: email, plan, country, app version. The flag service looks up targeting rules and a rollout percentage, then returns a boolean or a value. Good SDKs cache the config and evaluate locally, so you are not adding a network hop to every page load. On Betterflag, evaluation happens at the edge, under 100ms globally.

Two details that bite people:

Stickiness. A 10% rollout should mean the same 10% of users, not a random 10% on every request. Assignment is hashed on the user id so a user does not flip between variants as they navigate.

Fail-open vs fail-closed. If the flag service is unreachable, does the feature turn on or stay off? For a marketing banner, fail-open is fine. For a new payments path, fail-closed. Pick it per flag, not globally.

When you actually need feature flags

The usual objection: "We are three people. Feature flags are an enterprise thing."

Fair concern, wrong conclusion. Enterprise teams have canaries, SREs, and a rollback culture. You have one production environment and a Slack channel. Your blast radius is 100% of users.

You need flags when:

• A bad change would take down checkout, auth, or billing.
• You want to ship to beta users without a separate build.
• An agent is writing features faster than you can read them. Deploy the code dormant, release when you have looked.
• You are tired of long-lived feature branches that rot.

You do not need flags for a weekend toy with no users. You also do not need them as a substitute for tests. Flags hide incomplete work. They do not make incomplete work correct.

Feature flags vs environment variables

Environment variables flip at deploy (or pod restart). Feature flags flip at request time, per user. If the whole process should share one value (a database URL, a secret, NODE_ENV), use an env var. If some users should see a feature and others should not, or you need to kill it without a deploy, use a flag. I wrote out the full split in feature flags vs environment variables.

What goes wrong

Flags are simple. Flag hygiene is not.

• Flag debt. A flag that has been 100% on for six months is an if you should delete. Set a removal date when you create it.
• Missing defaults. If the SDK cannot reach the service, your app still has to render something.
• PII in targeting. Do not send raw emails or names as flag attributes if you can send a hash or a plan id.
• Testing only the "on" path. The off path is still production code.

Feature flag best practices covers the operational ones. The short version: name flags after the feature, not the ticket; default new flags off; never nest flags inside flags.

Do you need a vendor?

You can build a flag service in a weekend: a Postgres table, an endpoint, a cached JSON blob. Plenty of teams do. Then they add targeting, percentage rollouts, audit logs, environments, SDKs, an edge cache, and a way for CI and agents to flip flags without a shared admin password. That is a product, and it is the build-vs-buy trap in miniature.

If you want open source you can run yourself, look at Unleash, Flagsmith, or GrowthBook. If you want a hosted, flags-only service with one pricing meter and an MCP server so Claude Code or Cursor can create the flag it just wrote, that is what I am building. Pricing is one meter: evaluations, unlimited seats, from $9.99/mo.

You may not pick Betterflag. That is fine. Pick something. The unsafe default is an if, a comment that says TODO: clean this up, and a revert at 4pm on a Friday.