Feature flags infrastructure

Feature flags (“feature switches”) are a system that lets you turn site features on and off without deploying code. The code with the new feature is already on the server, but it is shown only when you “flip the flag”: to everyone at once, to 5% of users, to your team for testing, or to a specific segment. If a feature breaks — you turn it off with one click (a kill switch: cut a feature without touching the rest of the site), without an urgent redeploy. This decouples feature activation from code deployment. Important and honest: deploys become more flexible, but also more complex — flags are an extra layer of logic that itself needs tracking and regular cleanup, otherwise you get more bugs and confusion, not less; we build that in. How it differs from A/B tests: feature flags do NOT answer the question “which variant is better” — that is the job of A/B tests (see the “A/B testing infrastructure” service); flags decide “who to show a feature to and when”. They often work together: a flag rolls out a variant, A/B measures the effect. We choose the tool: managed cloud ones (LaunchDarkly, Split.io, ConfigCat) with a ready panel, or open-source on your server (Unleash, Flagsmith, GrowthBook). About money, honestly: managed ones charge a subscription (for example, LaunchDarkly from about $10 per user a month and up), and over a year this often exceeds the one-off implementation budget, so we help plan it right away; open-source ones are free but need support and hosting. Picture this: you ship a new cart, turn it on for 5% first — something is off, you turn it off with one click, and the rest do not even notice. The base price starts from 30,000 ₽ for the setup; it depends on the tool and integrations.

• Every new feature is a risky deploy: if it breaks, fixing and redeploying is stress and downtime.
• You cannot show a feature to some users or to your team — only to everyone at once.
• If a new thing “did not land” or has bugs, you cannot turn it off quickly — an urgent redeploy is needed.
• Releases go out “all or nothing” — there is no gradual, safe rollout.

• Choosing the tool (LaunchDarkly / Split / ConfigCat or open-source Unleash / Flagsmith / GrowthBook)
• Connecting feature flags to the site (frontend and/or backend)
• Gradual rollout: to a % of users, a segment, by geo or device
• A kill switch — instant turning off of a feature on a failure
• Targeting: show a feature to the team, a beta group, specific users
• A flag management panel for your team
• Tracking, lifetimes and cleanup of stale flags — so tech debt does not pile up
• Documentation and handover to the team

• More flexible, calmer deploys — you ship the code and turn the feature on when you are ready
• It broke — you turned it off with one click, without an urgent redeploy and downtime
• Gradual releases — a new thing is seen by some users first, less risk
• You can test on your team and a beta group before a full launch

• You leave a request and describe the stack and tasks (gradual releases, kill switch, targeting)
• We choose the tool, connect flags to the frontend and backend, set up the panel
• We implement it, show the team, and hand it over with documentation and flag-cleanup rules

• How are feature flags different from A/B tests?

  An A/B test (see the “A/B testing infrastructure” service) compares variants and tells you WHAT converts better. Feature flags do not do that — they are about managing rollout: WHO to show a feature to and WHEN, and how to turn it off instantly. The goal is different: measurement versus release control. Technically they are close and often work together: a flag rolls out a variant, A/B measures the effect, but these are two different jobs.

• Which tool to choose and how much does it cost afterwards?

  Managed cloud ones (LaunchDarkly, Split.io, ConfigCat) are convenient but charge a subscription — for example, LaunchDarkly from about $10 per user a month and up; over a year this often costs more than the setup itself, so we plan the budget right away. Open-source ones (Unleash, Flagsmith, GrowthBook) are installed on your server for free, but need support and hosting. We choose one for the team and budget and tell you about the recurring costs in advance.

• Won’t the flags turn into a dump?

  It is a real risk: if flags are not removed after a release, tech debt piles up, forgotten conditions and extra branches appear in the code, and the team spends time untangling it. So we build in flag tracking, their lifetimes and regular cleanup right away — a flag should be a temporary tool, not an eternal “if” in the code.