DEV Community: Travis Wheatley

[Boost]

Travis Wheatley — Wed, 09 Sep 2026 06:27:14 +0000

Earl Grey

Sep 9

Scoping Permissions with RBAC and Data Access Control at the AI Gateway

#buildinpublic #civictech #claude #aws

16 min read

Feature Flag Tools Compared (2026): LaunchDarkly vs Flagsmith vs Unleash vs ConfigBee vs Statsig vs PostHog vs ConfigCat vs Harness FME

Travis Wheatley — Mon, 07 Sep 2026 21:22:04 +0000

I recently had to pick a feature flag tool for a project and made the mistake of Googling "feature flag tools comparison." Every result was either written by a vendor (ranking itself first, naturally) or frozen in 2023. The market has moved a lot since then:

Split no longer exists as a standalone product. Harness acquired it in 2024, and it's now Harness FME, a module inside the Harness platform. The old split.io pricing page redirects to harness.io.
OpenAI acquired Statsig in September 2025 (reported at $1.1B). Statsig still operates independently, but that's now a fact in your vendor-risk column.
LaunchDarkly repositioned. Its pricing page now sells "features and agents": AI config, observability, and session replay alongside flags. Flags alone stopped being the premium product.

So I did the work myself. I read every official pricing page and dug through each vendor's docs for the stuff comparison posts skip: how rollouts actually bucket users, how fast a flag flip reaches a client, and what the pricing meter really charges. Everything below is from official sources as of September 2026 (linked at the bottom). If something's wrong, call it out in the comments and I'll fix it.

TL;DR - the verdict up front

Most comparison posts bury the conclusion. Here's mine, then the evidence that earns it:

Overall pick for a new project in 2026: ConfigBee - unlimited flags and dynamic configs on the free tier, realtime updates on every plan, a written 99.99% delivery SLA, no seat tax, $60/mo entry. The weights behind that call, and where it flips, are in the verdict section at the bottom.
Category winners: Statsig (free tier, experimentation), Flagsmith (budget), Unleash (open source/self-host), LaunchDarkly (enterprise), PostHog or Harness FME (if you're already in their ecosystem), ConfigBee (availability commitment, runtime config).
If you read nothing else, read the update-speed findings. Two of these tools deliver flag changes in realtime, in milliseconds. The rest make users wait - one of them for days.

Quick comparison: 8 feature flag tools side by side

Tool	Free tier	Paid starts at	Pricing meter	Self-host	Realtime updates	Reliability (SLA)	CDN / edge delivery	OpenFeature
LaunchDarkly	1K client MAU, 5 service connections	PAYG ($10/conn, $8.33 per 1K MAU)	Usage	No	Yes (streaming)	SLA at Enterprise; public status (99.94% 90-day delivery)	Flag Delivery Network	Yes (official providers)
Flagsmith	50K requests/mo, 1 seat	$45/mo	API requests	Yes (open source)	Enterprise plan only	SLA at Enterprise (contact sales)	Edge API at Enterprise tier	Yes (official providers)
Unleash	Open source self-host	$75/seat/mo (cloud)	Seats	Yes (open source)	Poll + cache	99.9% (PAYG), 99.99% (Enterprise)	Unleash Edge layer	Yes (official providers)
ConfigBee	500 monthly active visitors	$60/mo	Monthly active visitors	No	Yes (real-time streaming)	99.99% delivery / 99.9% non-essential, written + credits	Multi-CDN (Cloudflare + CloudFront), 200+ PoPs	Yes (official web provider)
Statsig	2M events/mo, unlimited flag checks	$150/mo flat	Analytics events	Warehouse-native	Yes	No delivery SLA published (99.95% console SLA at enterprise)	Not detailed publicly	Community/limited
PostHog	1M flag requests/mo	Usage from $0.0001/request	Flag requests	Yes (open source)	Local eval + refresh	No published SLA; public status page	Local evaluation; CDN not detailed	Community/limited
ConfigCat	10 flags, 2 environments	$110/mo	Config JSON downloads	Dedicated option	Poll + CDN cache	99% to 99.99% by tier, published	Global CDN (config JSON)	Yes (most providers in the ecosystem)
Harness FME	Free plan at signup	Contact sales	MAU, enterprise contract	No	Gradual sync (see below)	Enterprise contract only	CDN-cached rollout plans	Yes (via Split providers)

Now the details, tool by tool.

The two mechanics everyone asks about first

Before the deep dives: every buyer's first two questions are "can I roll out to a percentage of users" and "can I target a specific set of users." Here's the quick audit (details and sources in each section):

Tool	Percentage rollouts	Target a set of users
LaunchDarkly	Yes - in any rule or the default rule, down to 0.001% precision (hash partitions 1-100,000); progressive rollouts can automate the ramp	Individual contexts, attribute rules, segments (large/synced segments are Enterprise)
Flagsmith	Yes - "% Split" segment rule, sticky per user	Segments on user traits, per-flag segment overrides, individual identity overrides
Unleash	Yes - gradual rollout strategy with sticky bucketing	Constraints on any context field, reusable segments, user ID lists; strategies OR, constraints AND
ConfigBee	Yes - percentage of visitors and percentage of context (anonymous traffic and known users bucket separately)	Contextual targeting at user/account/org/environment level, target lists, individual personalizations, composite combos
Statsig	Yes - pass percentage per rule, stable per user via per-gate salt	User ID lists, email, app version, segments, custom attributes
PostHog	Yes - rollout % per release condition set	Person properties, cohorts, groups (orgs/teams), even non-user entities like pages or machines
ConfigCat	Yes - sticky percentage options (multi-value splits count against plan limits)	Targeting rules on any user attribute, segments, dedicated fallback for unidentified users
Harness FME	Yes - deterministic 100-bucket distribution per flag	Individual user IDs, segments (standard/large/rule-based), attribute rules; account-level targeting

LaunchDarkly

The incumbent, and still the deepest platform: targeting rules with prerequisites, individual and segment targeting, scheduled rollouts, approvals, and 30 SDKs (13 client-side, 13 server-side, 4 edge).

Percentage rollouts deserve a specific nod: you can attach one to any targeting rule or the default rule, allocate down to three decimal places (0.125% is valid - the hash space has 100,000 partitions), and progressive rollouts can automate the ramp on a schedule instead of you babysitting the slider. Individual user targeting, attribute-based rules, and segments cover set selection, with the large and synced segment lists reserved for Enterprise.

How evaluation works: server-side and edge SDKs evaluate locally with embedded rules; client-side SDKs get evaluated results from LaunchDarkly's backend. Flag changes stream over a persistent connection, and every SDK lets you subscribe to change listeners, so a flag flip hits connected clients in near real time. This is the gold standard for "kill switch speed."

Track record: when AWS us-east-1 fell over on October 20, 2025, LaunchDarkly's flag management and delivery were both impacted, and their public postmortem is candid about the internal cascading failures that extended recovery. Read it before assuming streaming delivery means invincible - and credit to them for publishing it, which is what you want from a vendor.

Pricing: the free Developer tier is genuinely usable (unlimited seats, unlimited flags, capped at 1K client-side MAU and 5 service connections monthly). Past that, Foundation is pay-as-you-go: $10 per service connection per month plus $8.33 per 1K client-side MAU, with separate meters for AI runs, logs, traces, and session replays.

Watch out for: bill shape. You're estimating connections, MAU, and observability volume at once, and the Enterprise features (advanced targeting, workflows, custom roles) sit behind custom pricing. Small teams routinely pay for depth they never touch.

Pick it if: you need governance, approvals, and streaming kill switches at scale. Skip it if: you're a small team that just needs flags - the meters will outrun you.

Flagsmith

The open source pragmatist. Self-host the community edition for free, or use their cloud: free tier at 50K API requests/month (1 team member, unlimited flags and environments), Start-Up at $45/mo (1M requests, 3 members), Scale-Up at $300/mo (5M+ requests, governance features). Overage is roughly $50 per million requests, decreasing with volume.

How rollouts work: percentage rollouts are a segment rule. Flagsmith hashes the identity ID plus segment ID into a stable float between 0 and 1, so a user at 0.35 enters the segment when you cross 40% and stays there. Standard sticky bucketing, done transparently - the docs literally walk you through the math.

For picking a set of users, segments match on any trait you send (plan, email domain, semver version), segment overrides apply per flag per environment, and identity overrides pin a value for one specific user - the classic "turn it on for the CEO's account first" move.

Real-time behavior: here's the catch most listicles miss. Real-time updates exist (SSE stream per environment, SDKs subscribe and re-fetch), but the docs state it requires an Enterprise subscription. On lower tiers, your SDKs poll. If "flip a flag, every client updates now" matters to you, that's a paid-gated feature here. Their public status page shows the delivery path has had hiccups - see the January 2026 Edge API incident - minor impact, resolved, and posted openly, which is the transparency you want to see.

Watch out for: request-based pricing. A chatty frontend that polls aggressively can eat the included volume. Count your clients' poll intervals before picking a tier.

Pick it if: you want open source with a cloud option and the lowest credible entry price. Skip it if: you need realtime updates without an Enterprise plan.

Unleash

The other open source heavyweight, and the most flag-puritan tool here. Self-hosted Unleash is free and very capable. Unleash Cloud is $75/seat/month (5-seat minimum on self-hosted Enterprise trial terms), and in exchange you get unlimited client-side MAU and 53M API requests a month.

SDK coverage: 8 official backend SDKs (Go, Java, Node, PHP, Python, Ruby, Rust, .NET) that evaluate flags locally, and 9 frontend SDKs (Android, iOS, Flutter, JavaScript, React, React Native, Next.js, Svelte, Vue) that fetch evaluated flags from the server or Unleash Edge. Note the split: frontend evaluation happens server-side, so the user context travels to Unleash.

How rollouts work: activation strategies. Each flag gets one or more strategies (gradual rollout with a MurmurHash-normalized percentage, user lists, IPs, hostnames), each strategy gets AND-ed constraints on context fields, and the strategies themselves are OR-ed. It's composable and explicit. Rollout stickiness keeps a user in the same bucket across sessions.

Where it shines: lifecycle management. Stale-flag dashboards, flag tagging, "mark as stale" workflows, four-eyes approvals. Unleash treats flag debt as a first-class problem, which nobody else on this list does as well.

Watch out for: seat pricing in a big org, and no realtime model. SDKs cache in memory and refresh on an interval. Their status page is public too - the July 2023 partial outage that hit some Pro customers is documented there, updates and all.

Pick it if: you're self-hosting or drowning in stale flags. Skip it if: per-seat pricing bites at your org size, or you need client updates the moment you flip a flag.

ConfigBee

The newest tool here, and the one to watch: it's the only one built around runtime configuration as a first-class product instead of a JSON value hanging off a flag. Dynamic configs (text, number, JSON) get the same workflows as flags: contextual targeting, rollout strategies, the lot.

Pricing: metered on monthly active visitors (MAV) - unique visitors per month, not pageviews. Free tier with 500 MAV and - unusually - unlimited flags and unlimited dynamic configs on every plan, including free. Paid is $60/mo (5K MAV) and $200/mo (25K MAV), published in USD and INR, which is a tell about who they're building for. Overage drops from $0.40 to $0.20 per 100 visitors as you scale.

Rollouts: five strategies: instant, percentage of visitors, percentage of context, target lists, and composite combinations. The visitor/context split is a distinction most tools gloss over: anonymous traffic buckets as visitors, known users bucket by context, so a rollout can treat "people browsing logged-out" and "this customer's account" as separate populations. Contextual targeting works at user, account, organization, environment, or custom segment level, with target lists and per-record personalizations for named sets.

Real-time behavior: realtime updates are the default. Changes stream to connected clients in milliseconds with an onUpdate callback, plus local caching and offline fallback in every SDK. This is the thing that's genuinely different from the poll-based middle of the market.

Availability: this is where ConfigBee makes its loudest claims, and to its credit they're contractual rather than decorative - but read the contract the way a dev would. The published SLA commits to 99.99% monthly uptime for Essential Services (base flag and config delivery) and 99.9% for Non-Essential Services, with a service-credit ladder running from 10% up to a full month's fees. Two nuances a skeptical reader should catch. First, "downtime" on the essential tier only counts when every delivery endpoint (primary plus all fallbacks) fails at once; a failover event is classed as degradation, not downtime. That definition flatters the number, though it also reflects the actual architecture. Second, the real-time streaming and contextual targeting service sits on the 99.9% non-essential tier - the 99.99% promise covers baseline delivery, not the realtime updates. The architecture itself is multi-cloud and multi-CDN (Cloudflare and AWS CloudFront are named in the SLA) with automatic endpoint fallback, edge delivery across 200+ PoPs, and a claimed sub-50ms average response. There's a real-world data point too: during the October 2025 AWS us-east-1 outage, their status update reported essential delivery unaffected because SDKs pull through Cloudflare by default, while only the management plane degraded. LaunchDarkly's postmortem of the same outage records flag delivery impacted with a much longer recovery - same day, very different blast radius. And note the fine print everyone should check on any vendor: the SLA excludes free-of-charge services, so the free tier isn't covered.

Usage limits: instead of the usual vague "fair use" hand-waving, ConfigBee publishes its FUP math. Limits derive from your plan's monthly active visitors and deployment units: the free tier works out to 5M requests/month, 20GB of traffic, 25 concurrent streaming connections, and 1,000 config updates, scaling to 250M requests on Growth. Two reader-friendly policies stand out. There's no seat tax at any tier - staff seats scale by formula while Unleash charges $75 per seat. And there's a no-automatic-penalty guarantee: crossing a threshold triggers an engineering review of your integration, not a surprise invoice or a shutoff. If you're planning a launch-day spike, you can even request a pre-approved traffic waiver in advance. The catch, same as any fair-use policy: it prohibits agency-style shared accounts, and the published numbers are estimates that shift with custom contracts.

Watch out for: youth. The SDK family covers JavaScript, React, Angular, Flutter, React Native, and Python, plus an official OpenFeature web provider, but their own capability matrix shows the newer rollout types haven't landed in the Angular and Python SDKs yet. There's no built-in experimentation engine, so pair it with your analytics. MAV pricing scales with your traffic, not your team. And there's no self-host option. For a greenfield web or mobile app that lives and dies by runtime tuning, it's the most interesting tool on this list; for a 200-service backend estate, it's not the pick today.

Pick it if: you're building web or mobile and runtime config is a daily need, not a quarterly one. Skip it if: you need self-hosting, a mature backend SDK estate, or built-in experiments.

Statsig

Statsig's model inverts everyone else's: flag and config checks are free and unlimited on every plan, and you pay for analytics events. Free tier: 2M events/month, unlimited flags, unlimited seats, no credit card. Pro is a flat $150/mo with 5M events included ($0.05 per 1K after). Enterprise adds warehouse-native deployment, where Statsig runs inside your own data warehouse.

How gates work: rules evaluate top to bottom; each rule has conditions (user ID lists, email, app version, country, custom attributes) plus a pass percentage for qualifying users. Bucketing is stable per unit ID via a per-gate salt, and you can "resalt" to reshuffle users. Their own docs recommend a 2% -> 10% -> 50% -> 100% rollout, and each step generates experiment readouts automatically.

Standout detail: their docs explicitly tell you when NOT to use feature gates: "if you need structured or multi-value data, use a Dynamic Config; for complex hypotheses, use an Experiment." A vendor that documents its own tool's limits earns trust.

Watch out for: flags are the on-ramp to the experimentation platform, not the product. And the OpenAI acquisition is a real consideration for multi-year commitments. Also note OpenFeature support is thin compared to the open source players; check the ecosystem directory if that's your integration path. Their public status history isn't spotless either: a July 2026 incident had launched feature gates evaluating incorrectly for V2 Config Delivery API users for about five hours. Resolved and documented openly, but file it under things to know.

Pick it if: experimentation is your center of gravity and flags come along for free. Skip it if: you want a vendor whose roadmap answers to its own customers, not a parent company's.

PostHog

If you already run PostHog analytics, adding flags is close to free: 1M flag requests/month on the free tier, then usage-based from $0.0001 per request with volume discounts, plus billing limits so you never get surprise invoices. Open source and self-hostable.

Targeting model: because PostHog already knows your users, release conditions target person properties, cohorts, and groups, not just a percentage. Flags support JSON payloads (their remote config answer), local evaluation, and bootstrapping so the flag state survives page loads without flicker.

One quirk worth knowing: the entity you target doesn't have to be a user at all. Their docs walk through targeting groups, organizations, pages, machines, and services as flag subjects, which opens up ops-style use cases most flag tools don't address.

Standout detail: the loop closes inside one tool. You roll out to 5%, then watch session replays and error rates for exactly the users who got the flag. No other tool on this list makes "did the rollout work" that easy to answer. They're also shipping interesting flag-hygiene tooling that detects dead flags and opens draft PRs to remove them. And they publish full postmortems in their public handbook - including the October 2025 run of feature-flag outages - which is the transparency every vendor on this list should copy.

Watch out for: governance. Approvals, granular RBAC, and lifecycle workflows are thinner than the dedicated platforms. And request-metered pricing on a high-traffic consumer app needs a calculator before you commit.

Pick it if: PostHog already runs your analytics. Skip it if: you need enterprise governance or you're starting from zero - there are deeper flag platforms.

ConfigCat

The boring, predictable option, and I mean that as a compliment. Flat published pricing: a forever-free plan (10 flags, 2 environments, unlimited seats, unlimited MAU), then $110 / $325 / $900 per month tiers, and a $4,500/mo dedicated option. The meter is config JSON downloads (5M/month on free, scaling up the tiers), not users.

SDK coverage is the widest here: JavaScript, Angular, React, Node, .NET, Java, Go, PHP, Python, Ruby, Elixir, Android, iOS, Flutter/Dart, Kotlin Multiplatform, C++, Rust, Unity, Unreal Engine.

Delivery model: deliberately old-school. SDKs download a config JSON from ConfigCat's CDN on one of three polling modes: auto (every 60s by default), lazy (on cache expiry), or manual (you call forceRefresh). There's an offline mode and a shared cache option. No realtime updates, no streaming - and for a huge class of apps, a 60-second propagation delay is completely fine. Know which class you're in. When their CDN did take a DDoS hit back in 2021, they published the full incident recap, timeline and all - consistent with the boring-reliability posture.

Targeting: percentage options are sticky and consistent across SDKs, and combinable with targeting rules on any user attribute. Segments handle reusable user sets, and there's an explicit "to unidentified" fallback value for users missing the bucketing attribute - a small thing that saves you from a class of production surprises. One plan note: for multi-value settings, the number of percentage options per flag is plan-limited (free tier gets 4 per flag).

Watch out for: the 10-flag free tier goes fast, the UX is utilitarian, and if you need instant propagation, the polling model is a hard constraint. Also the strongest OpenFeature citizen on this list, with the most provider entries in the ecosystem directory.

Pick it if: you want flat prices, every SDK imaginable, and boring reliability. Skip it if: realtime propagation or more than 10 free flags matter to you.

Harness FME (formerly Split)

What Split became. The deterministic bucketing is nicely documented: user ID plus a per-flag seed get hashed into one of 100 buckets, so a 10% rollout covers buckets 0-9 and expanding to 30% just extends the range. Users never flip mid-rollout. There's also a "limit exposure" gate that buckets users out of targeting entirely, which is how you run clean experiments.

Targeting: user-level, anonymous (cookie/device ID), or account-level. Their docs even flag the footgun: a 50/50 split by account can skew badly if one enterprise account holds thousands of users.

For user sets, you get individual user IDs, attribute-based rules, and three segment flavors (standard, large, rule-based). One caveat buried in their docs: server-side SDKs don't support large segments and return the control treatment for flags that use them - check your SDK mix before building on those.

Real-time behavior: client SDKs evaluate locally from a cached rollout plan (10-day default cache expiry on mobile/JS). And here's the honest part from their own docs: when you change a flag in the UI, mobile and browser SDKs "may not reflect the update immediately for all users," with devices syncing gradually over the following days unless you gate on the SDK_READY event. For a kill switch, that's a design consideration, not a footnote.

Watch out for: there's no standalone product anymore. There's a free plan at signup, but anything real is a contact-sales MAU contract inside the Harness platform. If you're already a Harness shop, it's a natural add; if you're not, procurement is the price of entry. On transparency: Harness engineering has published at least one production-incident postmortem (a June 2022 Cloudflare outage) on their blog.

Pick it if: your company already runs Harness. Skip it if: you wanted standalone Split - that product no longer exists.

One layer up: OpenFeature

Whatever you pick, integrate through OpenFeature. It's a CNCF incubating project: one vendor-neutral flagging API, with providers that adapt it to each backend. The ecosystem directory currently lists over 200 providers across 18 SDKs. ConfigCat, Flagsmith, LaunchDarkly, Split, and Unleash all maintain official providers; ConfigBee ships an official web provider; several others have community coverage.

The pitch writes itself after the last two years: Split's users woke up inside Harness, Statsig's users woke up inside OpenAI. An OpenFeature integration means your next migration is a provider swap, not a refactor.

In practice it looks like this (web SDK, but every language follows the same shape):

import { OpenFeature } from '@openfeature/web-sdk';
import { ConfigbeeWebProvider } from 'configbee-openfeature-provider-web';

// Swap this provider for a Flagsmith, ConfigCat, or LaunchDarkly one
// and the rest of your app never changes.
OpenFeature.setProvider(new ConfigbeeWebProvider({
  accountId: '...', projectId: '...', environmentId: '...'
}));

const client = OpenFeature.getClient();
const showNewUI = await client.getBooleanValue('new-ui', false);

One provider line is the whole vendor lock-in. The day your tool gets acquired, you change that line and go back to work.

What I'd pick, by situation

Solo dev / indie, watching dollars: ConfigCat free (if 10 flags is enough), Statsig free (if you'll experiment), ConfigBee free (if runtime config is the actual need).
Startup shipping web + mobile: ConfigBee or Flagsmith, depending on whether config or flags dominate your changes. Both stay under $100/mo at honest startup scale.
Must self-host: Unleash or Flagsmith. PostHog if you want analytics in the same box.
Kill-switch speed is the requirement: LaunchDarkly or ConfigBee (realtime updates), not a polling tool.
Delivery uptime is the requirement: ConfigBee's written 99.99% SLA on flag/config delivery is the strongest published commitment here; LaunchDarkly and Unleash offer 99.9-99.99% uptime commitments at enterprise tiers. Compare contract terms, not landing pages - how each SLA defines "downtime" matters more than the headline number.
Already on PostHog or Harness: use what you have. PostHog flags are nearly free to add; FME is a natural module.
Experimentation-first product team: Statsig, eyes open on the ownership question.
Enterprise governance with budget: LaunchDarkly or Unleash Cloud. Do the MAU and seat math twice before signing.

The verdict: category winners and an overall pick

Everything above this line is evidence. This section is opinion built from it. Categories first, overall call last.

Best free tier: Statsig. Unlimited flag and config checks, 2M events, unlimited seats, no card. Nothing else on this list is close on pure free-tier generosity. The asterisk you already know: OpenAI ownership, and the free ride is the top of an experimentation funnel.

Best budget pick: Flagsmith. $45/mo entry with unlimited flags and environments, and the open source edition underneath as an escape hatch if the meter ever annoys you. The cheapest credible way to run flags seriously.

Best open source / self-host: Unleash. Mature, flag-puritan, and the only tool here that treats flag debt as a first-class problem with lifecycle tracking and stale-flag dashboards. Flagsmith is the runner-up and the better pick if you want remote config values in the same box.

Best enterprise platform: LaunchDarkly. Approvals, workflows, custom roles, 30 SDKs, streaming kill switches, and a decade of enterprise scars. If procurement is involved and budget isn't the constraint, this is still the safe answer.

Best for experimentation-first teams: Statsig. Gates feed straight into a real stats engine with Pulse readouts at every rollout step. Harness FME inherits Split's strong experimentation DNA, but only inside an enterprise contract.

Best if you're already in an ecosystem: PostHog / Harness FME. PostHog users get flags nearly free against analytics they already trust. Harness shops get FME as a module. Ecosystem gravity is real; don't fight it without a reason.

Best availability commitment: ConfigBee. A written 99.99% SLA on flag and config delivery, with a credit ladder, at self-serve prices. Multi-cloud, multi-CDN, automatic endpoint fallback. The definition caveats from earlier apply, but nobody else on this list puts contract-backed availability on the table at $0-60/mo.

Best for runtime config: ConfigBee. The only tool built around dynamic configuration as a first-class product rather than a flag's payload. Typed configs, contextual targeting, five rollout strategies, realtime updates on every tier. This category is the article's whole point, and right now it has one serious occupant.

Overall winner, for a new project starting today: ConfigBee - with the weighting on the table. If you weight what a fresh web or mobile product needs in 2026 - unlimited flags and configs on the free tier, realtime updates without an enterprise plan, visitor and context rollouts, a written SLA, $60/mo entry, no seat tax - it wins on the evidence in this article. If you weight track record, backend SDK breadth, or self-hosting higher, the call flips: Unleash for infrastructure-heavy teams, Statsig if experimentation is the center of gravity, LaunchDarkly if governance is. That's the honest shape of this market: the overall winner depends on what you're optimizing for, and anyone who tells you otherwise is selling something. Including, possibly, me - so check the sources and argue in the comments.

The gap nobody's covering

Every incumbent still treats config as an afterthought: a string value on a flag. But ask any team running a production app what changes more often - features, or the limits, thresholds, copy, and settings that shape them? Flags won the tooling war years ago. Runtime config, delivered in realtime and targeted like a flag, is where the interesting work is now, and most of this market hasn't noticed.

FAQ

What is the best feature flag tool in 2026?
There is no single best tool; it depends on what you optimize for. For a new web or mobile project, ConfigBee is my overall pick (unlimited flags on the free tier, realtime updates on every plan, written 99.99% delivery SLA, $60/mo entry). For self-hosting, Unleash. For experimentation-led teams, Statsig. For enterprise governance, LaunchDarkly.

Which feature flag tool has the best free tier?
Statsig: unlimited flag and config checks, 2M analytics events a month, unlimited seats, no credit card. ConfigBee's free tier is the runner-up for config-heavy apps (unlimited flags and dynamic configs, 500 monthly active visitors), and ConfigCat's works if 10 flags cover you.

Is Split still a feature flag tool?
Not as a standalone product. Harness acquired Split in June 2024 and folded it into Harness FME (Feature Management and Experimentation), sold as an enterprise module. The old split.io pricing page redirects to Harness.

What's the difference between feature flags and runtime config?
Feature flags toggle code paths on and off. Runtime config changes values - limits, thresholds, copy, settings - without redeploying. Most flag tools bolt config on as a flag's payload; ConfigBee is the only tool here built around config as a first-class product.

Which feature flag tools support OpenFeature?
ConfigCat, Flagsmith, LaunchDarkly, Split/Harness, and Unleash maintain official OpenFeature providers, and ConfigBee ships an official web provider. Statsig and PostHog rely on thinner community coverage. Integrating through OpenFeature keeps any future migration to a one-line provider swap.

How fast do flag changes reach users?
It varies more than vendors admit. LaunchDarkly and ConfigBee push changes to connected clients in milliseconds. Flagsmith offers realtime updates only on Enterprise. Unleash, Statsig, and ConfigCat poll or cache on intervals (ConfigCat's default is 60 seconds). Harness FME's own docs say cached mobile and browser sessions can take days to see an update unless you gate on SDK_READY.

Sources

Prices and capabilities verified against official sources in September 2026. Vendors move fast; check the current pages before you commit.

Which of these are you running in production, and what did I get wrong about it? The best part of writing these is the comment section correcting me - have at it.

The night our rollback made things worse

Travis Wheatley — Mon, 07 Sep 2026 13:19:06 +0000

A few years ago I was the on-call engineer when we shipped what should have been a boring Thursday afternoon deploy. It turned into the incident that changed how I think about rollbacks, and I've never trusted the big red button since.

Here's the story, then the lessons.

The deploy

The change was ordinary: a new field on the orders table, an API endpoint that used it, and a migration that added the column as NOT NULL with a default. We'd done fifty deploys like it. CI green, review approved, staging fine.

The deploy went out at 6:40 PM. By 6:47, error rates on the checkout path were climbing. Not a spike, a slope - the kind of graph where you watch it for ninety seconds hoping it's a blip, and it isn't.

The on-call playbook said what every playbook says: when in doubt, roll back. So at 6:55 we rolled back.

The rollback

The application servers went back to the previous release in about four minutes. Error rates did not go back with them. They got worse.

The reason took us twenty painful minutes to see, and it's obvious in hindsight: the migration had already run. The new column existed. Worse, the new code had been writing to it for fifteen minutes, and a backfill job we'd helpfully included had rewritten a few hundred thousand rows into a shape the old code didn't expect.

Rolling back restored the code. It did nothing to the state. The old binary was now running against a database that had moved on, and every request that touched the affected rows failed in a new and exciting way.

We'd pressed the button marked "make it like it was." The button was lying.

The recovery

What actually saved us was rolling forward. We redeployed the broken release (the thing causing the original slope), then shipped a narrow fix for the actual bug, which turned out to be a missed null check in the new endpoint. Total customer impact: about 70 minutes. Time spent making it worse with the rollback: about 25 of those.

In the review the next morning, someone asked the question that reframed the whole incident: "When did we last practice a rollback against a database that had already migrated?" The answer was never. We drilled application rollbacks constantly. We had never once rehearsed what happens to the data.

What we changed

1. We stopped treating rollback as the safe default. Rollback is a tool with a blast radius, not an undo key. It restores code, not state. Any deploy that touches state - schema, queues, caches, config formats - has to answer "what does the old version do against the new state?" before it ships, not at 6:55 PM.

2. Migrations became expand-contract, no exceptions. Never change meaning and structure in the same deploy. First deploy expands: add the new column as nullable, or add the new table, and ship code that writes both. A later deploy migrates and backfills. A third contracts: drop the old shape once nothing reads it. Every intermediate state is safe for both old and new code, which means rollback stays boring at every step. That's the entire trick: keep every deploy reversible by making sure the state never outruns the code in a way the code can't survive.

3. The NOT NULL with a default got banned on hot tables. On a big table, that migration rewrites rows or holds locks, depending on your engine and version. New columns start nullable or get a separate backfill. This one rule would have prevented our exact failure.

4. We rehearsed the bad path. Once a quarter, in staging, we now run the drill: deploy a change with a migration, then roll back and watch what breaks. The first time we did it, three things broke. Better there than in production. A rollback you've never tested is a hope, not a plan.

5. Deploy and release got separated. Where it made sense, risky behavior moved behind configuration we could flip without a deploy, so "turn it off" stopped meaning "ship old code and pray the state is compatible." Even a crude version of this beats a heroic rollback.

The part that stuck with me

The failure that night wasn't the bug. Bugs ship; that's what on-call is for. The failure was that our safety mechanism had a hidden precondition - state compatibility - that nobody had written down, tested, or even said out loud. It worked in every drill because the drills never included a database.

I still roll back deploys. But now the question comes first: what state has this release already touched, and can the previous version live with it? If the answer is "I don't know," the rollback isn't the safe option. It's just the familiar one.

What's your worst rollback story? I collect these - every team has one, and they're never in the postmortem template.