Feature flags

A feature flag is a switch you control from leadmaps that turns part of your product on or off, without you having to release new code each time. You create a flag in the dashboard, give it a name, and decide who should get it. Your app then asks leadmaps “is this flag on for the person in front of me right now?” and leadmaps answers yes or no. Flip the switch in the dashboard and the change reaches your users in seconds, with no new deploy.

Think of it like the light switches in a building that the front desk controls. The wiring is already in the walls. The front desk does not rewire anything to turn the lights on in one room: it just flips a switch. A feature flag is that switch for your product. The code for the new feature is already shipped and sitting quietly behind the flag, and you decide from the dashboard which users see it light up.

This is useful for three big reasons. You can release a new feature to a small slice of users first and watch how it goes before everyone gets it. You can turn a feature off instantly if it misbehaves, without an emergency deploy. And you can give specific people, like beta testers or one important customer, early access without changing anything in your code.

What you see

The page lists your flags and lets you create, target, and flip them.

• A page title that reads “Feature flags”.
• A list of your flags. Each flag shows:
  • Its name. The short key your app uses to ask about it, for example new_checkout or dark_mode.
  • Its state. Whether it is on, off, or partly on (rolled out to a share of users). A clear on or off control sits on the row so you can flip it.
  • Its rollout. What percent of users currently get it, for example “5 percent” while you are testing, or “100 percent” once it is fully live.
  • Its rules. Any targeting rules attached to it, for example “on for users in Germany” or “on for the pro plan”.
• A way to create a new flag, where you set its name and its starting state.
• A detail view for a single flag, where you set the rollout percent, add or edit targeting rules, and turn the whole flag fully on or fully off.

A flag can answer with more than a plain yes or no. It can also return a small value, called a payload, so the same flag can carry a bit of configuration, for example which headline text to show, not just whether a feature is on.

How to read it

Read a flag as three questions: is it on at all, what share of users get it, and who specifically.

Here is a worked example. Say you built a new checkout and you want to release it carefully. You create a flag named new_checkout, set its rollout to 5 percent, and add a rule “always on for the pro plan”. The flag row now reads:

• Name: new_checkout.
• State: on.
• Rollout: 5 percent.
• Rules: on for plan = pro.

What does this tell you, and what actually happens to your users? Everyone on the pro plan gets the new checkout, because the rule names them directly. On top of that, a randomly chosen 5 percent of everyone else also gets it, so you gather real feedback from a small, mixed group. The other 95 percent keep the old checkout for now. The same person keeps getting the same answer each visit, so a user does not flip between the old and new checkout from one page to the next, which would be confusing.

Now say the new checkout looks healthy after a day. You open the flag and raise the rollout to 50 percent, then later to 100 percent. Each change reaches your users within a minute or so, no deploy needed. And if something had gone wrong instead, you would set the flag to fully off, and every user would drop back to the old checkout at once. That instant off switch is the whole point: a bad feature is one click away from being gone.

Check a flag in your app

Your app reads flags through the leadmaps tracking library. You turn the feature on at startup, then ask about a flag by name. Every read is instant, because the answers are cached on the device and refreshed quietly in the background.

import { init } from '@syntarie/tracking';
import { getFeatureFlag, onFlagsLoaded } from '@syntarie/tracking/feature-flags';

// Turn on flag loading when you start leadmaps.
init({
  apiKey: 'lk_live_yourkey',
  host: 'https://collect.leadmaps.nl',
  featureFlags: true,
});

// Wait until the flags have arrived, then ask about one by name.
onFlagsLoaded(() => {
  if (getFeatureFlag('new_checkout') === 'treatment') {
    showNewCheckout();
  } else {
    showOldCheckout();
  }
});

A flag answers with the variant the current user should see. A simple on or off flag answers treatment when it is on for this user and control when it is not. If the flags have not arrived yet (for example on the very first load, before the answers are cached), a read falls back to a safe default you choose, so your app never waits or breaks while it learns the answer.

Customize it

You shape who gets a flag and when. Here is each control and when to use it.

• Create a flag. Make a new flag and give it a clear, short name that your app will use to ask about it. Create a flag whenever you build something you want to release gradually or be able to switch off. Pick the name before you write the code so the dashboard and your app agree on it.
• Set the rollout percent. Choose what share of users get the flag, from 0 to 100 percent. Use a small percent like 5 to test a new feature on a few real users first. Raise it step by step as your confidence grows. Set it to 100 percent once the feature is ready for everyone. The same user always lands on the same side of the split, so the experience stays steady for each person.
• Target by rules. Add rules that turn a flag on for a specific group, for example by country, by plan, or by another property you send about the user. Use rules when you want certain people to get a feature regardless of the random percent, such as all paying customers, or only users in one country where the feature is ready. Rules and the rollout percent work together: a rule names a group directly, while the percent covers a random slice of everyone else.
• Flip fully on or off. Turn the whole flag on or off instantly. Use the off switch as an emergency brake the moment a feature causes trouble, so every user drops back to the safe behavior at once without a deploy. Use the full on switch when a feature has proven itself and you want everyone to have it.

Use cases

• Release a new feature to a small group first. Create a flag, set the rollout to 5 percent, and ship the new feature behind it. Watch how that small group behaves on your funnels and feedback pages before widening. Action: if the early 5 percent shows healthy numbers and no complaints, raise the rollout step by step to 25, 50, then 100 percent. If something looks off, drop the rollout back down while you fix it, with no deploy needed.
• Keep a kill switch on a risky feature. Wrap any feature that touches money, sign in, or data behind a flag from day one. Action: if that feature starts causing errors or confusion in production, set its flag to fully off at once. Every user returns to the safe path instantly, which buys you time to fix the real problem calmly instead of scrambling for an emergency release.
• Give chosen customers early access. Create a flag for a feature you are not ready to show everyone, and add a rule that turns it on for a specific plan or a named group of beta testers. Action: invite those customers to try it, gather their feedback, and only once it is solid remove the rule and raise the rollout so the rest of your users get it too.

Tips

• Name flags clearly and decide the name up front. Your app and the dashboard both use the flag’s name, so pick a short, plain key like new_checkout before you write the code, and avoid renaming it later, which would mean changing both sides at once.
• Always read a flag with a safe default in mind. On the very first load the answers may not have arrived yet, so design your app to show the safe, existing behavior until the flag’s answer is known. A feature that breaks while it waits for a flag defeats the purpose of the flag.
• Roll out in steps, not in one jump. The value of a flag is that you can test on a few users before all of them. Going straight from 0 to 100 percent throws away the safety net. Climb the percent as your confidence grows.
• Clean up flags you no longer need. Once a feature is fully live for everyone and proven, the flag has done its job. Leaving many old flags around makes the list harder to read and the code harder to follow, so remove a flag and its branch once the decision is final.
• The off switch is your friend. The single most valuable thing a flag gives you is the power to turn a misbehaving feature off in one click, with no deploy. Put your riskiest changes behind a flag for exactly this reason.