Toggled

Use cases

Feature flag service use cases product teams rely on

A feature flag service is one mechanism with many jobs: safer releases, cleaner branches, honest experiments and instant recovery. Here is what teams actually do with it, by scenario and by role.

No card required

01 · By scenario

Six jobs, one flag system

feature.checkout-v2

Trunk-based development

Merge to main daily behind flags instead of nursing week-old branches. Reviews stay small, integration pain disappears, and unfinished work ships dark.

Trunk based development
rollout: 1%

Canary releases

Expose new code to 1% of real traffic and watch error rate and latency before anyone else sees it. No second cluster, no load-balancer surgery.

Canary deployment
beta = true

Beta programs

Target beta = true users with the next feature, collect feedback, widen the cohort when it holds. Opt-in chaos becomes a rule.

How targeting works
kill switch

Instant rollback

When the new path regresses, flip it off for everyone in about 3 seconds. The deploy stays; the incident ends.

Kill switch
A/B: 50 / 50

A/B experiments

Split traffic between variants with sticky cohorts and read conversion per variant. Ship the winner with the same slider.

A/B testing
plan = pro

Plan entitlements

Gate premium features with plan = pro rules. Packaging changes become rule edits, not deploys, and sales unblocks itself.

Targeting rules

02 · By role

Who reaches for the toggle, and why

Owns release safety

Staff engineer

Wants kill switches and canaries wired into the pipeline without an enterprise sales cycle. Gets both, plus audit history for the postmortem that now stays short.

Ships weekly

Full-stack engineer

Wants to merge to main and stop babysitting branches. Wraps work in a flag, ships dark, flips it on for the team on Friday.

Answers for incidents

Engineering manager

Wants smaller blast radius and a bill that does not grow with headcount. Rollback drops from 45 minutes to about 3 seconds; the invoice ignores hiring.

Owns the metric

Product manager

Wants to know whether the feature helped. Attaches conversion to the rollout and reads the answer instead of arguing about it.

Runs the paved road

Platform lead

Wants one flag system across React, Node, Python, Go and mobile, not four homegrown ones. SDKs share the same hashing, so cohorts agree everywhere.

Swipe for more roles

03 · Starting point

Start with one flag, not a migration

Nobody adopts a feature flag service by converting their codebase. You adopt it by wrapping the next risky feature in one flag and feeling the difference on release day. If you are outgrowing a config-file toggle system or a per-seat bill, the moves are the same: pick one feature, one flag, one rollout.

Coming from the incumbent? The LaunchDarkly alternative page maps concepts one to one. Running your own? Read open-source flags vs a managed platform for the honest trade-off.

Week one with Toggled

  1. Day 1 Drop the SDK into one service, wrap one feature.
  2. Day 2 Ship dark. Flip it on for the internal team.
  3. Day 3 Add beta users by rule, collect feedback.
  4. Day 4 Roll to 10% of everyone, watch the guardrails.
  5. Day 5 Hit 100%, delete the old path, name the next flag.

Early access · launching soon

Pick your first flag; we handle the rest

Join the early-access list and be first in line when spots open. Flat pricing, unlimited seats, no card required.

No card required · your data stays yours

Keep exploring

More feature flag resources