Log in
Guide

What are feature flags?

Feature flags let you ship code switched off, then turn it on for a share of users — or everyone — without another deploy. Here's how they work, and how Split Test Pro's feature flags help you release safely and prove what works.

Feature flags, explained

A feature flag — also called a feature toggle — is a named on/off switch your code checks before showing a feature. Instead of a release being the moment code goes live, it becomes a setting you can change at any time. That separates deploying code from releasing it.

Release gradually

Turn a feature on for a small share of users first, then widen it as you gain confidence.

Switch it off fast

If something goes wrong, turn the flag off — no rollback, no emergency deploy.

Test before you commit

Show different versions to different users and measure which one works better.

How feature flags work

Your code wraps the new behaviour in a check. When a user arrives, the flag is evaluated for them — on or off — and your code shows the matching experience. The rules behind that answer live outside your code, so changing who gets the feature is a setting, not a deploy.

checkout.js
if (isEnabled(user, "new-checkout")) {
  showNewCheckout();   // users the flag is on for
} else {
  showOldCheckout();   // everyone else — today's experience
}

Most flag systems let you set a rollout percentage — the share of users who get the feature — and keep each user's answer stable, so the same person sees the same thing on every visit.

How Split Test Pro's feature flags work

In Split Test Pro you manage flags in Settings → Feature flags. Each flag has a key your code uses, an on/off switch, a rollout percentage and a Kill button. Your backend reads them with the Node SDK or the evaluation API from any language.

Rollouts that never take a feature away

Each user's place in a rollout is a fixed hash of their id and the flag key. Raise the rollout from 10% to 50% and the first 10% keep the feature while 40% more get it. Different flags hash differently, so the 10% of one flag isn't the same users as the 10% of another.

A kill switch, and a safe default

Kill serves false to everyone immediately — including users inside the rollout and any running experiment. Changes reach your servers immediately through the API, and within 30 seconds by default through the Node SDK's cache. The rollout percentage is kept, and Restore returns the flag to off, ready to turn on again.

Five lines of code

Install @splittestpro/node, add your server API key, and check the flag:

checkout.js
import { SplitTestPro } from "@splittestpro/node";

const stp = new SplitTestPro({ apiKey: process.env.SPLITTESTPRO_API_KEY });

if (await stp.isEnabled(user.id, "new-checkout")) {
  renderNewCheckout();
}

The SDK caches results, never throws into your request path, and needs no runtime dependencies.

Flags and A/B tests, together

Most flag tools stop at on and off. In Split Test Pro, an experiment's variants can set flag values, so you can A/B test a feature behind a flag and read the result with the same Bayesian stats as any other test.

  1. Build behind the flag

    Ship the new code path with the flag off. Production is unchanged.

  2. Test it

    Run an experiment whose variant turns the flag on, against a control that leaves it off.

  3. Roll it out

    Raise the rollout step by step — or, on Pro and Agency, roll out the winning variant straight into the flag.

  4. Clean up

    Once the feature is everywhere, remove the check from your code and delete the flag.

Feature flags are included on every paid plan. A workspace can hold up to 100 flags, and only workspace owners can manage them. For setup details, see the Feature Flags documentation, or see Split Test Pro's feature flags at a glance.

Questions