Feature flag

A feature flag wraps new behavior in a condition: if the flag is on for this user, show the new thing, otherwise show the old one. Because the check happens at runtime, you can change who sees what without a deploy. For a small team this separates two things that are usually tied together: shipping code and releasing a feature.

Four kinds of flag

Martin Fowler's well-known article on feature toggles sorts them into four categories, which differ in how long they live and how they are decided:

• Release toggles let you merge unfinished work and keep it dark until ready. They should last days or weeks.
• Experiment toggles drive A/B tests, keeping each user in the same group long enough to produce valid data.
• Ops toggles control operational behavior, such as turning off a heavy feature during an outage. Some kill switches stay permanently.
• Permissioning toggles limit a feature to certain users, such as paying customers or beta testers. These can live for years.

The fourth kind is closest to product packaging. Gating a feature to a higher pricing tier is a permission flag, whether or not you call it that.

What you get

• Safer releases. Roll out to 5% of accounts, watch errors, then widen. Turn it off in seconds if something breaks.
• Beta programs. Give one customer early access without a separate branch.
• Customer-controlled rollouts. EnterpriseReady recommends that larger customers be able to choose when new features reach their users, using flags that account admins control, together with an in-app changelog.
• Smaller, more frequent merges rather than long-lived branches.

The cost: flags are inventory

Fowler's central warning is that savvy teams treat toggles as inventory with a carrying cost and keep it as low as possible. Every flag doubles the paths through the code you need to test. Stale flags nobody dares to remove become technical debt. His suggestions: add a removal task when you create the flag, give flags an expiry date, or cap the total number allowed.

Build or buy

A first version is a database table or config file and an if statement. That is enough for a long time. Hosted services (LaunchDarkly, PostHog, Statsig, GrowthBook and similar) add targeting rules, percentage rollouts, audit logs and an interface for non-engineers. Buy when product or support staff need to flip flags themselves, or when you run experiments often.

When a small SaaS should care

Almost immediately for one use: releasing risky changes to a few accounts first. Skip the platform until you have more than one engineer or run regular experiments. Name flags clearly, record an owner and a removal date, and delete them once a feature is fully live. Flags also help you ship a minimum viable version to a small group and see whether anyone uses it.

Related terms

• Changelog
• Sandbox environment
• Technical debt
• Tiered pricing
• MVP (Minimum viable product)

Sources

• Feature Toggles (aka Feature Flags), Martin Fowler
• Change management, EnterpriseReady