Feature Flags: When a Config File Is Enough, and When to Buy a Platform

Feature flags are one of the few engineering practices that almost everyone agrees on and almost everyone over-buys. The idea is small: put the new thing behind a switch, ship the switch off, turn it on when you are ready. The market built on that idea sells seats, environments, monthly active users and service connections, and it is easy to end up paying for a rollout system when what you needed was a boolean.

We have run flags three ways at different sizes: a hand-rolled object in config, a self-hosted open-source server, and a paid platform. Each was right at the time. This is how we tell which one you are at.

The config-file version, and what it covers

The simplest flag is a typed object checked into the repository, with an environment variable that can override each key at boot. That gives you three things immediately: dark launches, where the code ships but the path stays off; kill switches, where a misbehaving feature comes out of the next deploy instead of a revert; and per-environment differences, so staging can run ahead of production.

Changing a flag is a deploy. People treat that as a disadvantage, and for a team whose pipeline stays under ten minutes it mostly is not. A deploy is reviewed, logged and reversible. A dashboard toggle is one click by whoever has the login.

What the file cannot do is vary by user. Every flag is on or off for everybody, and nobody outside the engineering team can touch it. Those two limits are the whole decision.

The three requests that mean you have outgrown it

A platform becomes worth its cost when one of these lands, and in our experience they arrive in this order.

• "Can you turn it on just for this customer?" Usually from sales or support, usually about a feature that is nearly ready. Per-account targeting in a config file means hard-coding account ids and redeploying for each one, and that gets old by the third request.
• "Can we roll it out to ten percent first?" Percentage rollouts need a stable hash of the user and a way to move the dial without a deploy. You can write that in an afternoon, and then you own it forever.
• "Two services need to agree." Once the web app and a worker both need to see the same flag at the same moment, a shared source of truth stops being optional. This is the same shape of problem as picking a job queue: the moment more than one process is involved, ad hoc stops working.

Buy a flag platform when a person who cannot deploy needs to change a flag, or when a flag needs to mean different things to different users. Not before.

What the platforms cost once you are there

The pricing models are not equivalent, and the difference is which number grows. Some charge for your team, some for your traffic, and some for your users. Which one hurts depends on the shape of your product.

Tool	Free tier	First paid step	What scales the bill
PostHog	1M flag requests a month, bundled with analytics	Usage-based beyond the allowance	Requests
LaunchDarkly	Developer: unlimited seats, 1 project, 3 environments, 5 service connections, 1K client-side MAU	Foundation: $10 per service connection, $8.33 per 1K client-side MAU billed yearly	Monthly users and connected services
Flagsmith	50K requests a month, 1 team member, 1 project	Start-Up: $40 a month billed yearly, 1M requests, 3 seats	Requests, then seats
Unleash	Open source, self-hosted: unlimited seats, 1 project, 2 environments	$75 per seat per month, five-seat minimum	Seats on your team, not your traffic

If you already send product analytics to PostHog, its flags are the obvious first stop: the same person properties you use for funnels become targeting rules, and one million requests a month is a long way for a small product. The catch is the same one as with any bundle — if you leave the analytics, you leave the flags.

LaunchDarkly's free plan is more generous on seats than people expect and more restrictive on users. One thousand client-side monthly actives is a beta, not a launch, and once you are on Foundation the MAU line is what grows. It is the right choice when you need approvals, scheduled changes and a very mature SDK in an unusual language, and it is overkill for a two-service app.

Flagsmith and Unleash are both open source, which matters if your policy is that anything in the request path has to be something you could run yourself. Flagsmith's hosted tier prices on requests; Unleash prices on people, with a five-seat floor. For a small team with a lot of traffic, that floor is the cheaper deal; for a large team with a small product, it is the expensive one.

The cost nobody quotes

Every platform puts an SDK in your request path and a network call in your startup. All of them cache aggressively and degrade to defaults if the service is unreachable, but you should know what those defaults are before the day the service is unreachable, because the flag you most want to flip during an incident is the one whose provider is also having one.

The other cost is the flags themselves. A flag is two code paths, both of which need tests, one of which is usually forgotten. Platforms will show you a list of stale flags; none of them will remove the dead branch from your codebase. Our rule is that a flag gets an owner and a removal date on the day it is created, and a scheduled job lists anything over ninety days old. Without that, the dashboard ends up looking like the wall in the photograph — dozens of switches, wired by people who have left, and nobody willing to touch any of them.

Where we landed

A config object with environment overrides until a non-engineer asks to flip something, or a flag needs to differ per user. Then PostHog if the analytics are already there, Flagsmith's hosted tier if not, and Unleash self-hosted only where somebody actively wants to own the server. LaunchDarkly when a procurement team is involved and the feature list has to match a spreadsheet. The same build-or-buy reasoning we used for authentication applies here, with a lower bar: flags are easy to build and easy to leave, so buy late and stay flexible.