How teams use FeatureSignals

Real workflows that help engineering teams ship faster, test safely, and recover from incidents in seconds.

Progressive Rollouts

Ship to 1% of users, then scale to 100%

Roll out new features gradually using percentage-based targeting with consistent hashing. The same user always sees the same variant, so their experience stays stable as you increase the rollout. If something breaks, dial it back instantly.

How it works

1Create a boolean flag for your new feature
2Set a 1% rollout in production
3Monitor error rates and user feedback
4Increase to 10%, 50%, then 100%

See it in code

# Set 10% rollout in production
curl -X PUT https://api.featuresignals.com/v1/projects/proj-1/flags/new-checkout/environments/env-prod \
  -H "Authorization: Bearer <token>" \
  -d '{
    "enabled": true,
    "rollout_percentage": 10
  }'

# Increase to 100% when confident
curl -X PUT .../flags/new-checkout/environments/env-prod \
  -H "Authorization: Bearer <token>" \
  -d '{ "enabled": true, "rollout_percentage": 100 }'

A/B Testing

Data-driven decisions with variant flags

Run controlled experiments with weighted variant assignment. Consistent hashing ensures each user always lands in the same bucket. Track impressions via the metrics API and pipe the data to your analytics tool of choice.

How it works

1Create a variant flag with control and treatment groups
2Set weights (e.g., 50/50 or 90/10)
3Instrument your app with impression callbacks
4Analyze conversion rates and pick the winner

See it in code

import { useStringFlagDetails } from "@featuresignals/react";

function PricingPage() {
  const { value } = useStringFlagDetails(
    "pricing-experiment", "control"
  );

  useEffect(() => {
    analytics.track("pricing_impression", { variant: value });
  }, [value]);

  return value === "treatment-a"
    ? <NewPricing />
    : <CurrentPricing />;
}

Kill Switch

Instant rollback when things go wrong

Wrap risky features in a flag and disable them in one click during incidents. No redeployment, no waiting for CI. The change propagates to all connected SDKs in seconds via SSE streaming.

How it works

1Wrap the risky code path behind a flag
2Deploy with the flag enabled
3If an incident occurs, toggle the flag off in the Flag Engine
4All SDKs receive the update in seconds via SSE

See it in code

# Emergency disable — takes effect in seconds
curl -X POST https://api.featuresignals.com/v1/projects/proj-1/flags/payments-v2/kill \
  -H "Authorization: Bearer <token>" \
  -d '{ "env_id": "env-production" }'

# All SDKs receive the update via SSE within seconds
# No redeploy needed

Trunk-Based Development

Merge to main every day, release when ready

Feature flags decouple deployment from release. Engineers merge incomplete work behind flags daily, eliminating long-lived branches and painful merge conflicts. Product decides when to flip the switch.

How it works

1Developers wrap work-in-progress behind a flag
2Merge to main daily — the flag keeps it hidden
3QA tests by enabling the flag in staging
4Product enables the flag in production when ready

See it in code

// Work-in-progress code merged to main daily
if (await client.isEnabled("new-payment-flow", { key: userId })) {
  // New incomplete feature — hidden from users
  return processPaymentV2(order);
}
// Stable code path — everyone sees this
return processPaymentV1(order);

Beta Programs & Early Access

Give power users early access to new features

Use segment-based targeting to enable features for specific user groups. Create a 'beta-testers' segment, add users by email or attribute, and they'll see the new feature while everyone else sees the stable version.

How it works

1Create a segment for beta testers
2Add rules: email ends with @company.com, or plan = 'enterprise'
3Create a flag targeting that segment
4Beta users see the feature, everyone else sees the default

See it in code

// Beta users automatically see the new feature
const enabled = await client.isEnabled("ai-assistant", {
  key: userId,
  attributes: {
    email: "power-user@enterprise.com",
    plan: "enterprise",
  },
});
// Server-side targeting rules:
//   segment "beta-testers" → email endsWith "@enterprise.com"
//   OR attribute "plan" equals "enterprise"

Multi-Environment Promotion

Test in staging, promote to production with confidence

Each environment has its own flag states and targeting rules. Test thoroughly in development and staging before promoting to production. Use Environment Comparison to spot drift and bulk-sync changes across environments.

How it works

1Enable the flag in development and iterate
2Use Env Comparison to verify staging matches dev
3Bulk-sync selected flags from staging to production
4Full rollout after validation

See it in code

# Compare flag states between staging and production
curl "https://api.featuresignals.com/v1/projects/proj-1/flags/compare-environments\
?source_env_id=env-staging&target_env_id=env-production" \
  -H "Authorization: Bearer <token>"

# Bulk-sync selected flags from staging to production
curl -X POST .../flags/sync-environments \
  -H "Authorization: Bearer <token>" \
  -d '{
    "source_env_id": "env-staging",
    "target_env_id": "env-production",
    "flag_keys": ["new-checkout", "dark-mode"]
  }'

Customer Support Debugging

"What does this user see?" — answered in seconds

When a customer reports an issue, use Entity Inspector to see exactly what flags they experience. Compare two users side-by-side to understand why one sees a feature and another doesn't. No code reading required.

How it works

1Customer reports: 'I can't see the new dashboard'
2Open Entity Inspector, enter their user key and attributes
3Instantly see all flag evaluations with reasons
4Compare with a working user to find the difference

See it in code

# See exactly what user-42 experiences
curl -X POST https://api.featuresignals.com/v1/projects/proj-1/environments/env-prod/inspect-entity \
  -H "Authorization: Bearer <token>" \
  -d '{
    "entity_key": "user-42",
    "attributes": { "plan": "free", "country": "US" }
  }'

# Returns: flag_key, value, reason for every flag
# → "new-dashboard": false, reason: "ROLLOUT" (not in 10% bucket)

Toggle Lifecycle Management

Categorize, track, and clean up flags systematically

Classify every flag into one of four categories — release, experiment, ops, or permission — each with tailored staleness thresholds and management guidance. Track lifecycle status from active through archived. Never let technical debt from stale flags accumulate again.

How it works

1Assign a category when creating each flag
2Flag Health uses category-aware staleness thresholds
3Move flags through active → rolled_out → deprecated → archived
4CI pipeline scans for stale flags and fails the build

See it in code

// Four toggle categories with different lifecycles:
//
// RELEASE    → 14-day staleness threshold
//               Trunk-based dev, canary rollouts
//
// EXPERIMENT → 30-day staleness threshold
//               A/B tests, multivariate experiments
//
// OPS        → 90-day staleness threshold
//               Circuit breakers, maintenance modes
//
// PERMISSION → 90-day staleness threshold
//               Plan gating, feature entitlements

Ready to try it yourself?

Start a 14-day free trial — full Pro features, no credit card required.

Start Free Trial Sign Up Free View Pricing