Skip to main content

Glossary

Feature Flag

Meaning and details

A feature flag is an if-statement driven by configuration instead of code. The same deployed binary serves some users the new checkout flow and others the old one, decided at runtime by user id, percentage, or a targetin...

Feature Flag meaning

A runtime switch that turns a code path on or off per user or percentage, without a new deploy.

What is Feature Flag?

A feature flag is an if-statement driven by configuration instead of code. The same deployed binary serves some users the new checkout flow and others the old one, decided at runtime by user id, percentage, or a targeting rule. Flip the switch and behavior changes in seconds, no redeploy.

Why it matters to an indie builder: flags decouple shipping from releasing. You can merge code on Friday and open it to 5 percent of users on Tuesday, watch error rates, then go to 100 percent, or kill it instantly if conversion drops. For a small team this is your rollback plan, your canary strategy and your A/B mechanism in one primitive. PostHog and Unleash ship flags as a feature; LaunchDarkley-era tooling exists if you outgrow them.

A concrete example: new pricing page. Ship it behind a flag defaulting to internal users. QA it in production (the real environment, real data). Roll to 5 percent of traffic, watch signup conversion and JS errors in PostHog for two days. Conversion holds: 50 percent, then 100 percent. A Junior dev breaks something at 100 percent? Flag off, old page back, zero deploy. Total blast radius of any mistake: minutes.

Common mistakes: flag debt (old flags never removed, code paths untestable, a year later nobody knows what flag "checkout_v2_cleanup" does: delete flags with a scheduled reminder the day you create them), too many flag combinations (every flag multiplies your test surface; three booleans is eight code paths), using flags for configuration they were not meant for (feature switches, not environment settings), and flagging without metrics: a flag you cannot measure is a coin flip, not a rollout. Wire every rollout to an error rate and a conversion metric before you flip anything.

A note on tooling weight: if you already run PostHog for analytics, its flags feature is enough for a long time. Standalone flag services earn their keep when you need per-environment overrides or your team grows past a handful of engineers. The analytics and productivity blocks here cover the common options.

Keep exploring the glossary