Feature flags: LaunchDarkly vs. Statsig vs. open source

This guide is for engineering leads and founders deciding how their team will ship code behind feature flags. A feature flag is a switch in your code, controlled from outside the deploy, that decides who sees a feature. Flags let you merge unfinished work, roll out to 5% of users, and turn off a bad release in seconds. The decision in front of you: pay a vendor like LaunchDarkly or Statsig, or run an open-source tool such as Unleash, Flagsmith, GrowthBook, or PostHog. The right answer depends less on features than on whether you need experiments, where your flags get evaluated, and how much you want to own.

The short answer

Choose LaunchDarkly if releases are your main concern and you want mature governance (approvals, scheduling, and workflows on Enterprise) with pricing based on server connections and client-side users rather than seats.

Choose Statsig if you mainly want experimentation with flags included, and you are comfortable with its 2026 change of ownership to Amplitude.

Choose GrowthBook or PostHog if you want flags plus experiments on a free or low-cost tier, and value open source.

Choose Unleash or Flagsmith if you want to self-host plain feature flags with no per-request fees.

Whatever you choose, call flags through OpenFeature so the vendor sits behind an interface you control.

What actually matters

Pure flagging or experimentation. Turning features on and off is a much simpler problem than running statistically sound A/B tests. Experimentation needs event data, metric definitions, and statistics. If you don’t run experiments, don’t pay for an experimentation platform.
What you’re billed on. Seats, server connections, monthly active users, events, or requests. Each model punishes a different architecture.
Where flags are evaluated. On your server, at the edge, or in the user’s browser or app. This drives latency, cost, and what user data leaves your systems.
Portability. How much code has to change if you switch tools.
Self-hosting and license. Whether you can run it yourself, and under what terms.
Vendor stability. Who owns the product and how likely its roadmap is to change. Statsig’s two ownership changes in under a year are the reminder here.

Pricing as of October 2026

All figures come from each vendor’s public pricing page as of October 2026.

LaunchDarkly. The Developer plan is free with unlimited seats, 5 service connections, and 1,000 client-side monthly active users (MAU), plus 100,000 experimentation MAU per month. The Foundation plan is pay-as-you-go at $10 per service connection per month and $8.33 per 1,000 client-side MAU per month (billed yearly), with no seat or platform fees. Enterprise is custom-priced, and Guardian (release monitoring with automatic rollback) is a separate add-on. Two terms matter. A service connection is one instance of one server-side SDK connected to one LaunchDarkly environment, measured in minutes, so one server connected for a full month is one service connection. Every running app instance in production and pre-production counts. Client-side MAU is the number of unique contexts (usually users) evaluated by client-side, AI, and edge SDKs in a month.

Statsig. The free Developer plan includes 2 million events per month and unlimited flag and config checks. Pro is $150 per month with 5 million events included, then $0.05 per 1,000 extra events. Enterprise is custom. Flag checks are not metered on any plan; you pay for the analytics events that feed experiments.

Statsig ownership. OpenAI announced on September 2, 2025 that it had signed a definitive agreement to acquire Statsig, and Statsig’s founder joined OpenAI. Statsig’s own blog now notes that Amplitude acquired Statsig on May 5, 2026: the product, brand, and customers moved to Amplitude, while the original team stayed at OpenAI. Industry coverage has raised the obvious question of how fast the product will move without the people who built it. Statsig’s pricing page still lists the plans above, but if you adopt it now, read the current terms and ask Amplitude about the roadmap.

Open source and open core.

Unleash is AGPLv3 open source. The free self-hosted edition is limited to 1 project, 2 environments, and 5,000 flags per instance, without SSO or change-request approvals. Paid Pay-As-You-Go is $75 per seat per month, with 53 million API requests a month included and $5 per million after.
Flagsmith is mostly BSD-3-Clause and free to self-host. Its cloud Free plan includes 50,000 requests per month and 1 team member; Start-Up is $40 per month (yearly) or $45 monthly for 1 million requests and 3 members; Scale-Up is $250 per month (yearly).
GrowthBook is open core: most code is MIT, with some directories under a commercial license. Self-hosting the open-source edition is free with unlimited flags and experiments, using your own data warehouse. The cloud Starter plan is free for up to 3 users; Pro is $40 per user per month.
PostHog bundles flags with product analytics. The first 1 million flag requests per month are free; after that PostHog’s own comparison guide lists $0.0001 per request, falling with volume.

Comparison table

Criterion	LaunchDarkly	Statsig	Unleash	Flagsmith	GrowthBook	PostHog
Main focus	Release management	Experimentation	Feature flags	Feature flags	Experiments and flags	Product analytics with flags
Billing unit	Service connections and client-side MAU	Analytics events (flag checks free)	Seats plus API requests	Requests and team members	Users, events, CDN requests	Flag requests
Free tier	5 service connections, 1k client MAU	2M events per month	Self-hosted open source	50k requests per month	3 users (cloud), or self-host	1M requests per month
Experimentation	A/B tests included	Core strength	Not the focus	A/B testing on paid plans	Core strength	Works with PostHog experiments
Self-host	No	No	Yes (AGPLv3)	Yes (BSD-3-Clause)	Yes (MIT open core)	Check current terms
OpenFeature provider	Vendor-published	Community-published	Vendor-published	Vendor-published	Vendor-published	Community-published

Experimentation vs. pure flagging

A flag answers “who gets this?” An experiment answers “did it help?” To answer the second question, a tool has to log which variant each user saw, collect outcome events (sign-ups, purchases), and run statistics that account for noise. That’s why Statsig and GrowthBook price around events or warehouses, while flag-first tools price around connections, seats, or requests.

If you’re pre-product-market-fit with a few hundred users, you probably can’t run meaningful experiments yet anyway, because small samples rarely reach a confident result. Start with plain flags. Add experimentation when you have enough traffic and a team that will actually act on results.

OpenFeature: the portability layer

OpenFeature is a Cloud Native Computing Foundation incubating project that defines a vendor-agnostic API for evaluating flags. Your code calls the OpenFeature SDK; a provider translates those calls to a specific tool. Hooks let you add logging or telemetry around every evaluation.

LaunchDarkly, Unleash, Flagsmith, and GrowthBook each publish OpenFeature providers on GitHub, and community providers exist for others. Language coverage varies, so check that your stack is supported before you commit. With OpenFeature in place, switching vendors becomes mostly a provider swap plus migrating flag definitions, which is still work, but not a rewrite of every if statement. Record the choice as a technical decision record.

Where flags are evaluated

Server-side evaluation. The SDK downloads the full ruleset and evaluates locally, so checks are fast and user data never leaves your servers. On LaunchDarkly this is what service connections measure, so many small instances (autoscaling containers, serverless functions) can add up. Unleash’s own best-practice guide recommends evaluating on the server to protect personal data.

Client-side evaluation. Browsers and mobile apps can’t safely hold the whole ruleset, because users can inspect it. LaunchDarkly’s client-side SDKs send the user’s context to LaunchDarkly, which returns only that user’s results, and each flag must be explicitly marked available to client-side SDKs. That means user attributes leave your systems, and you pay per client-side MAU. Never put sensitive targeting rules or personal data you can’t share with the vendor into client-side contexts.

Edge evaluation. Edge SDKs evaluate flags inside a CDN provider using synced flag data, so you avoid a round trip per flag and keep latency low for server-rendered pages. On LaunchDarkly, edge SDK evaluations count toward client-side MAU.

The rule of thumb: evaluate on the server by default, pass only the result to the client, and use edge evaluation when page-render latency matters.

Flag debt and cleanup

Every flag is a fork in your code. Leave enough of them in place and nobody knows which paths are live. Unleash’s guidance is blunt: make flags short-lived and treat them like technical debt. In practice:

Give every flag an owner and an expiry date when it’s created.
Separate release flags from permanent ones. Kill switches and entitlement flags can live for years; release flags should be gone within weeks of reaching 100%.
Add removal to the definition of done. The ticket isn’t finished until the flag and its dead branch are deleted.
Review stale flags on a schedule. Most tools surface flags that haven’t changed or been evaluated recently. Look at that list every sprint.
Archive, don’t just delete, in the tool so the audit trail survives.

Which one for you

Solo founder. PostHog’s free 1 million requests or Flagsmith’s free tier will cover you, and LaunchDarkly’s Developer plan works if you stay within 5 server connections. Don’t self-host anything yet.

Growing startup running experiments. GrowthBook if you already have a data warehouse; PostHog if you want analytics and flags in one place. Statsig is technically strong, but weigh the ownership change.

Platform team with many services. Count your server instances before choosing LaunchDarkly, since per-connection pricing scales with your fleet. Self-hosted Unleash or Flagsmith avoids per-instance fees if you can run them.

Regulated company. Favor server-side evaluation and self-hosting so user attributes stay inside your boundary. If you buy, confirm data residency, SSO, and audit log retention on the specific plan. This is a real build vs. buy call; building your own flag service is easy to start and hard to finish well.

Mistakes to avoid

Calling vendor SDKs directly from everywhere. Wrap them, ideally with OpenFeature.
Paying for experimentation you won’t use. Flags alone are cheap.
Ignoring the billing unit. Serverless and autoscaling can multiply server connections; a popular mobile app can multiply client-side users.
Sending personal data to client-side flag services by default.
Never deleting flags. Flag debt is quiet until an old flag flips during an incident.
Building your own and stopping at a boolean in a config file. Percentage rollouts, targeting, audit logs, and a UI are where the real work is.

A quick checklist

Decide whether you need experiments now or only flags.
Count server instances, monthly active users, and expected flag requests.
Choose where each flag is evaluated: server, edge, or client.
Check the license and self-hosting terms of any open-source option.
Confirm the vendor’s current ownership and roadmap.
Adopt OpenFeature and confirm a provider exists for your languages.
Require an owner and expiry date on every new flag.
Schedule a recurring stale-flag review.