Feature Flags in 2026: Types, Tools and A/B Testing

Feature flags (also called feature toggles) are runtime switches that separate deploying code from releasing a feature. In 2026 they are the standard mechanism for progressive delivery, kill switches, entitlements and A/B testing, and OpenFeature has made the vendor choice reversible. This guide covers the four flag types, deployment, A/B testing, tooling and hygiene.

What feature flags are and the four flag types

A feature flag is a conditional whose value comes from configuration, not from the build. The code asks "is new-checkout enabled for this user?" and rules you can change at runtime answer. The code path ships; the flag decides whether anyone reaches it.

Flags fall into four types with different lifetimes, risk profiles and owners. Confusing them is the root cause of most flag debt.

Type	Purpose	Typical lifetime	Changes how often	Owner
Release flag	Ship unfinished or risky code dark, then ramp it up	Days to weeks	Rarely, then deleted	Feature team
Experiment flag	Randomize users into variants to measure an effect	Length of the experiment	Never during the test	Product + data
Ops flag / kill switch	Disable a dependency, degrade gracefully, cap load	Permanent	Rarely, under incident	Platform / SRE
Permission flag	Entitlements: plan tiers, beta cohorts, internal users	Permanent	Per-customer changes	Product / support

A release flag still in the code six months later is a bug; a kill switch still there six years later is doing its job. Permission flags are business logic that happens to use the flag SDK and need the same tests and audit trail as any authorization rule.

Under the hood, a control plane (dashboard, rules, audit log) feeds SDKs. Server SDKs pull the full ruleset and evaluate in-process, so a check costs microseconds and survives a control-plane outage. Client SDKs receive already-evaluated values, because shipping rules to a browser would leak segments and targeting.

How feature flags change your deployment strategy

Without flags, deploy and release are the same event. With flags, deploy becomes a non-event: the binary reaches production with the new path off, and the release happens later, on a dashboard, one cohort at a time. That decoupling is what makes trunk-based development workable: unfinished code merges to main daily because it sits behind a flag.

Flags complement the infrastructure-level approaches in our post on blue-green, canary and rolling deployments. The difference is granularity:

• A canary deployment routes a percentage of traffic to a new binary. It catches crashes and latency regressions in the whole build.
• A flag rollout exposes a percentage of users to a new code path inside the same binary. It isolates one feature and can target by attribute: staff first, then one region, then 10% of everyone.

A practical sequence:

1. Deploy with the flag off. Confirm the new path emits telemetry and does nothing for users.
2. Enable for employees and QA. Fix what they find without another deploy.
3. Ramp by percentage with sticky assignment, watching error rate, latency and the feature's business metric at each step.
4. Reach 100%, wait one release cycle, delete the flag and the old path.

Reverting a deploy takes minutes and affects every change in the build; flipping a flag takes seconds and affects one feature. In a CI/CD pipeline, that means fewer emergency releases.

A flag is only a safe rollback if the old path still works. Database migrations are the usual trap: apply them expand-and-contract style so both paths run against the same schema. Our guide to database migrations in production covers the pattern.

Feature flags vs A/B testing: where the line is

Flags and A/B tests are layers, not competitors. An A/B test is a flag plus three things flags do not provide: randomization, measurement and statistics.

Aspect	Feature flag rollout	A/B test
Question answered	"Is this safe to ship?"	"Is this better than what we had?"
Assignment	Progressive, by attribute or percentage	Random, fixed for the duration
Changes during run	Ramp up or roll back freely	Do not touch the split
Metrics	Operational: errors, latency	Product: conversion, retention, revenue
Ends when	100% and cleanup	Pre-agreed sample size is reached
Requires stats	No	Yes

The part vendor marketing skips: most teams lack the traffic for A/B tests on most features. Detecting a small change in a conversion rate takes tens of thousands of users per variant, sometimes far more, and the sample grows rapidly as the effect gets smaller. A B2B product with a few thousand monthly active users cannot run a meaningful test on a checkout tweak; it should decide on qualitative feedback and a flag rollout instead.

If you do have the traffic, the rules are simple to state and easy to break:

• Fix the primary metric, minimum detectable effect and sample size before starting; GrowthBook and PostHog include calculators.
• Do not peek and stop early. Run to the planned sample or use a sequential method the tool supports explicitly.
• Add guardrail metrics (error rate, load time, support tickets) so a "winning" variant that breaks something is caught.
• Hash assignment from a stable user ID so a user gets the same variant across sessions and devices.
• Run one experiment per surface at a time unless the tool manages mutual exclusion.

If a tool offers "experimentation" without sample-size guidance and confidence intervals, treat it as a rollout tool with a chart attached.

Feature flag tools compared in 2026

The market has consolidated around a few commercial platforms, a few strong open-source projects, and OpenFeature as the neutral API layer.

Tool	Hosting model	SDK coverage	Targeting	Experimentation	Pricing model	Open source
LaunchDarkly	SaaS (relay proxy for on-prem evaluation)	Broadest: server, client, mobile, edge	Rich segments, contexts, scheduled changes	Built-in, with stats engine	Per seat plus usage; enterprise-oriented	No
Unleash	Self-hosted (Docker/Helm) or managed cloud	Server and client SDKs for major languages	Strategies, constraints, segments	Basic variants; stats via external tools	Free OSS core; paid enterprise features and cloud	Yes
Flagsmith	Self-hosted or SaaS	Server, client, mobile, edge	Segments, identities, overrides	Multivariate flags; analytics through integrations	Free tier; per-request and per-seat tiers	Yes
GrowthBook	Self-hosted or SaaS	Server, client, mobile	Attribute targeting, saved groups	Strongest OSS stats: frequentist and Bayesian, sequential testing, warehouse-native	Free OSS; paid cloud and enterprise	Yes
PostHog	SaaS or self-hosted	Server, client, mobile	Person properties, cohorts	Integrated with product analytics; stats included	Usage-based, per flag request	Yes
OpenFeature	Not a service: a spec and SDKs	Every major language; providers for the tools above	Delegated to the provider	Delegated to the provider	Free	Yes (CNCF)
Homegrown	Your database or config file	Whatever you write	Usually boolean or percentage	None	Engineering time	N/A

How to read this:

• LaunchDarkly is the reference for scale, governance and SDK breadth, and the most expensive; cost scales with seats and monthly contexts.
• Unleash is the pragmatic self-hosted choice for teams that want flags inside their own network. Experimentation is thin by design.
• Flagsmith is lighter, with per-identity overrides that suit B2B products enabling features per customer.
• GrowthBook is the pick when experiments matter more than flags; it reads metrics straight from your data warehouse.
• PostHog makes sense if you also want product analytics and session replay from one vendor and accept usage-based billing.
• OpenFeature is not a competitor. Code against its API and switching vendors later becomes a provider swap, not a rewrite.
• Homegrown means a features table and an admin page. It works for a dozen flags with no targeting; the moment someone asks for "10% of users in Germany", you are rebuilding Unleash with fewer tests.

A short OpenFeature example

OpenFeature gives you one API regardless of backend. Swapping LaunchDarkly for Unleash later means changing only the provider.

import { OpenFeature } from "@openfeature/server-sdk";
import { InMemoryProvider } from "@openfeature/server-sdk";
// In production: import a vendor provider, e.g. from @openfeature/launchdarkly-server-provider

const provider = new InMemoryProvider({
  "new-checkout": {
    disabled: false,
    variants: { on: true, off: false },
    defaultVariant: "off",
    contextEvaluator: (ctx) => (ctx.plan === "enterprise" ? "on" : "off"),
  },
});

await OpenFeature.setProviderAndWait(provider);
const client = OpenFeature.getClient();

export async function checkout(user: { id: string; plan: string }) {
  const useNewCheckout = await client.getBooleanValue(
    "new-checkout",
    false, // safe default when the provider is unavailable
    { targetingKey: user.id, plan: user.plan }
  );

  return useNewCheckout ? newCheckoutFlow(user) : legacyCheckoutFlow(user);
}

Three details matter more than the syntax: the default (false) is what runs if the provider is down, so it must be the safe path; targetingKey is the stable ID that makes rollouts sticky; and the context carries only the attributes rules need.

Flag hygiene: how feature flags become technical debt

Every flag is a branch that has to be understood, tested and eventually removed. Teams without a cleanup process end up with hundreds, nobody knows which are safe to delete, and the dashboard becomes a source of incidents. These are the practices that matter.

Every flag has an owner and an expiry. Record both at creation, in the tool's metadata or a manifest in the repo. Release flags expire two to four weeks after planned full rollout, experiment flags with the experiment, and permanent flags are marked permanent so a cleanup script never touches them.

Naming encodes intent. release-new-checkout, exp-pricing-page-cta, ops-disable-recommendations, perm-advanced-reporting. A reviewer can tell from the name whether the flag should still exist.

Removal is part of the feature. A PR that adds a release flag does not merge without a ticket to remove it.

Automate the nag. LaunchDarkly, Unleash and GrowthBook all report stale flags; send that weekly to the owning team. A script that diffs flag keys in the codebase against the tool catches the reverse: flags deleted in the dashboard but still evaluated in code.

Keep the count visible. Flags past expiry belong next to lead time and change failure rate. If it climbs, cleanup is losing to feature work.

Remove rather than keep "just in case". Once the new path has been at 100% for a release cycle, the old path is not a rollback plan. Version control has it.

Testing with feature flags

Flags multiply code paths, and untested paths reach production. Three levels keep this under control.

Unit tests use an in-memory provider. Never hit the real flag service from tests. With OpenFeature, InMemoryProvider lets a test run the code with new-checkout true, then false. Both branches are covered explicitly.

Integration and E2E suites run against the states that will exist in production. Not every combination; that explodes combinatorially. Many teams run E2E twice in CI: with the default flag set, and with all release flags forced on, the state after the next ramp.

Test the configuration, not just the code. A targeting rule is data that can be wrong. Manage flags as code (Unleash, Flagsmith and LaunchDarkly have Terraform providers) so changes go through review, and check in the pipeline that each flag's default is the safe one: old behavior for release flags, "enabled" for a kill switch guarding a dependency you want on. In a distributed system, a misconfigured flag in one service cascades.

Security: flags are not authorization

A client-side flag evaluation can be read and modified by the user; the SDK payload is visible in DevTools. That is fine when the flag hides a beta UI. It is a vulnerability when the flag is the only thing between a user and a paid feature or another tenant's data.

• Enforce on the server. The frontend uses the flag to show the "Export report" button; the API checks the same flag, or better the actual entitlement, before returning the export. Never trust client-side evaluation for authorization.
• No secrets or PII in flag rules. Segment names and flag keys ship to client SDKs.
• Restrict who can flip what. Kill switches and permission flags need a specific role or second approver, and a queryable audit log.
• Treat flag changes as production changes. They bypass CI. A flag flipped at 17:55 on a Friday is a deploy without a pipeline; on-call should see it next to deploys and alerts.

Entitlements that depend on contracts and billing belong in an authorization model, not a flag; our post on modern authentication and zero trust covers where those checks live.

Decision checklist

Choosing a tool

• Targeting beyond on/off and percentage? If not, a config file or small table is enough for now.
• Real A/B tests with enough traffic for significance? Shortlist GrowthBook, PostHog or LaunchDarkly. If not, do not pay for experimentation.
• Flag data must stay in your network? Unleash or Flagsmith self-hosted; LaunchDarkly with the relay proxy if budget allows.
• Features enabled per customer (B2B)? Prioritize per-identity overrides and an API support tooling can call.
• Write against OpenFeature from day one; it is the cheapest insurance against lock-in you will buy.
• Count dashboard seats. Seat-based pricing gets expensive when product, support and QA all need access.

Adding a flag

• Which of the four types is it? Name it accordingly.
• Who owns it and when does it expire?
• What is the safe default if the flag service is unreachable?
• Does the old code path still work after any schema change?
• Is there a server-side check if the flag gates access, not just UI?
• Is there a ticket to remove it?

Recommendation

Adopt feature flags for release control first, with ownership and expiry from day one; that alone removes most deploy anxiety and enables trunk-based development. Code against OpenFeature so the vendor is replaceable. Choose Unleash or Flagsmith if flags must stay self-hosted, LaunchDarkly if you need enterprise governance and can afford it, GrowthBook or PostHog if experiments are the point. Run A/B tests only where traffic makes them meaningful, and say so when it does not. Keep authorization on the server and delete flags as deliberately as you add them. At Arvucore we usually recommend starting with a self-hosted open-source tool behind OpenFeature and upgrading only when a specific capability justifies it.