When does a small release need a feature flag?
Use a feature flag when you want to change who gets a feature without shipping a new copy each time. Before adding a tool, check that your app can keep its old path working alongside the new one.
Do you need a flag, an experiment or a simple preview?
Choose based on the decision you need to make next. You can start by letting someone try a change without introducing a new service.
| Question | Start here |
|---|---|
| Can someone get through the new screen? | Use a test copy and watch someone try it. |
| Can a small group use it while everyone else keeps the old version? | Use a flag that your app checks when choosing between the two paths. |
| Does one version help more people finish? | Use an experiment with a stable assignment and a result you can count. |
How do you practice turning a change off?
Try the release on paper first. Imagine a new signup page that should appear only for a test group. Use made-up people and list what each should see before and after the switch changes.
- Write down the first two casesA tester in the group sees the new page. Another visitor still sees the existing signup page.
- Turn the switch off on paperBoth should get the old page once the app applies the new setting. Decide what someone who is halfway through signup should see.
- Work out what should happen offlineA new browser may have no value. A returning browser may have an earlier value. Choose the safer path for each case and write down how you would check it.
- Try it in a disposable copy if you have oneBefore clicking through, verify that the copy uses only test accounts, records and email destinations and cannot contact live services. Stay on paper if you cannot verify the setup.
Compare tools
Scroll the table sideways to read every column.
| Tool | How do you choose who gets it?The way the app can give different groups different behavior. | When does the change take effect?What the app needs to read and what can delay the result. | What do you need to measure it?How the tool connects a version to what people do. |
|---|---|---|---|
| PostHog | Use a flag with targeting rules or a rollout percentage. | Your app must evaluate the flag and use the result. Check identity and what happens when the result is unavailable. | A PostHog experiment can use the flag and your app events. Check exposure and the outcome before reading results. |
| Statsig | Use a Feature Gate for selected users or a percentage of an eligible group. | Your app checks the gate. In a browser it may use a saved value when a new fetch fails. | Use an experiment to assign variants and compare outcomes for the identity you choose. |
| GrowthBook | Use the SDK connection for the right environment and target a test group or a percentage. | The app reads the flag. JavaScript can use a cached configuration or a fallback when no usable value is available. | Match assignment and outcome events in a managed or connected data source. |
| LaunchDarkly | Target users or accounts, or select a percentage of eligible contexts. | Set an off variation and a fallback in the app. An initialized library may keep using its last known rules during a disconnect. | Attach metrics to an experiment with the versions and context kind you want to compare. |
| Flagsmith | Use an individual override, a segment rule or the environment default. | The app reads the flag. Browser defaults and saved values can affect what appears before an update arrives. | The experiment beta needs a supported library and somewhere to store its events. A self-hosted evaluation can use its existing database. |
| Unleash | Use rules for an environment, including named groups or a percentage with a stable identifier. | The app can keep using saved values until it receives an update. Check behavior before any flag data is available. | Use variants to assign versions and record impressions and outcomes in analytics. |
| ConfigCat | Set targeting rules or percentage options using the attributes your app supplies. | The library evaluates from downloaded settings. Refresh timing and the app fallback matter. | Send the served version or variation ID to an analytics setup that records the outcome. |
| Firebase | Add Remote Config to your app and choose which parameter each condition supplies. | The app needs a default and must fetch and activate changes. The timing depends on its setup. | Remote Config experiments use Google Analytics and support web, Android and iOS. The separate rollout setup has its own platform requirements. |
| OpenFeature | The provider decides who gets a flag. The app asks through a common interface. | Provider initialization and refresh behavior vary. The app supplies a default for a missing answer. | Use a compatible provider or integration to record assignments and outcomes for analysis. |
| Optimizely Web Experimentation | Choose a website page and audience for a browser experiment. Create variations in the editor or with code. | The page script applies an eligible experiment in the browser. Load timing can affect what appears first. | Choose an outcome metric and check that it records successful actions for the version served. |
Can turning a feature on grant access to a private record?
Keep the permission check where your app handles the request. A rollout setting can choose which screen to show. The service that saves or returns the record still needs to decide what the signed-in person may do.
Keep the flag decision separate from an account’s role or paid access. Turning off a new signup path also cannot unsend a confirmation or reverse data the new path already saved. Plan for those effects before depending on the switch.
How do you tell whether an experiment has answered the question?
Pick one outcome before you start, such as completing signup, and decide what a meaningful difference would look like. First check whether the data shows which version each participant saw.
Watch a second signal, such as errors during signup, so a better completion count does not hide a problem. If your app has very little traffic, a difference of two signups may have several explanations. Treat the result as uncertain and watch real people use the two versions in a safe test copy if that would answer the immediate question.
When can you remove the switch?
Decide who owns the flag and what would make you remove it. For a temporary signup change, choose which path to keep, remove the decision from the app and check that your supported app versions no longer read the flag before deleting it.
A switch that remains for emergencies has a different job. Document what it controls and keep checking that the fallback still works after other releases.