Turn features on without a deploy, roll them out to a share of users, and switch them off instantly when something goes wrong. Then A/B test them — all in one app.
Deploy new code with the flag off. Production is unchanged until you flip the switch — no redeploy to turn it on.
Start at 10%, then 25%, then everyone. Users who already have the feature keep it as you raise the percentage.
Something wrong? Kill serves false to everyone immediately — and reaches every Node SDK server within 30 seconds by default.
Let an experiment set the flag per variant, read the Bayesian results, then roll out the winner straight into the flag.
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.
npm install @splittestpro/node, add your server API key, and check the flag. The SDK caches results and never throws into your request path.
Not on Node? Call the evaluation API from any language — it's the same API.
import { SplitTestPro } from "@splittestpro/node";
const stp = new SplitTestPro({ apiKey: process.env.SPLITTESTPRO_API_KEY });
if (await stp.isEnabled(user.id, "new-checkout")) {
renderNewCheckout();
}false is always the safe valueKilled, off, outside the rollout, an unknown key, a failed request — every one serves false. Name flags so false means "what users get today", and an outage or a kill always falls back to the known-good path.
falsefalsefalsefalsefalseMost flag tools stop at on and off. Split Test Pro measures what the flag did to revenue. New to flags? Read what feature flags are and how they work.
Ship the new code path with the flag off. Production is unchanged.
Run an experiment whose variant sets the flag on, against a control that leaves it off.
Rolling out a winning variant writes its value into the flag — on at 100%.
The flag keeps serving the winner until you remove the check from your code.
