Ever deployed code on a Friday and spent the weekend worried something might break? Or wished you could test a new feature with just 10% of your users before rolling it out to everyone?

Feature flags solve these exact problems. They let you ship code to production and decide later - or gradually - who actually sees it.

What are feature flags?

A feature flag (also called a feature toggle or feature switch) is a condition in your code that controls whether a feature is active. The condition is evaluated against a value you can change from a dashboard without touching the code or deploying again.

import {
  SupashipClient,
  FeaturesWithFallbacks,
} from '@supashiphq/javascript-sdk'

const FEATURE_FLAGS = {
  'new-dashboard': false,
  'premium-features': false,
} satisfies FeaturesWithFallbacks

const client = new SupashipClient({
  sdkKey: process.env.SUPASHIP_SDK_KEY,
  environment: 'production',
  features: FEATURE_FLAGS,
  context: { userId: user.id, plan: user.plan },
})

// Evaluate the flag for the current user
const showNewDashboard = await client.getFeature('new-dashboard')

if (showNewDashboard) {
  renderNewDashboard()
} else {
  renderLegacyDashboard()
}

The flag starts false in production. When you're ready to release - to 10% of users, to beta testers, or to everyone - you flip it from the dashboard. No deployment required.

The core idea: separate deployment from release

Before feature flags, shipping code and releasing a feature were the same event. You merged, deployed, and users immediately saw the change. If something broke you had to either roll back (risky) or rush a fix (stressful).

Feature flags break that coupling:

1. Deploy your code with the new feature wrapped in a flag (set to off)
2. Release by turning the flag on in the dashboard - for 5% of users, specific users, or everyone
3. Monitor how the feature performs with real traffic
4. Adjust the rollout or turn it off instantly if something looks wrong

Your deployment becomes a non-event. The release becomes a controlled, reversible process you can run on your own schedule.

Types of feature flags

Most flags start as percentage rollouts and graduate to global once you're confident.

What feature flags make possible

Confident deployments

You can merge to main and deploy whenever the code is ready, knowing the feature is hidden behind a flag. No more coordinating releases, waiting for deployment windows, or waking up at 3am because something broke in production.

Smaller blast radius

If a bug slips through, it only affects the percentage of users who have the flag enabled. With 5% rollout, 95% of your users never see the problem. You turn off the flag and fix it without a fire drill.

Instant rollbacks

No emergency deploys, no rollback scripts. One toggle in the dashboard and the feature is off. Users on the broken experience immediately fall back to the stable version.

Trunk-based development

Long-lived feature branches create merge conflicts and slow teams down. With feature flags you merge incomplete code behind a flag daily, keeping the team on a single branch. No more "integration week."

Beta and early-access programs

Enable a flag only for specific user IDs or segments to build an internal beta group. Your most engaged users get early access; everyone else sees the stable experience.

Kill switches for risky integrations

Third-party APIs fail. Payment providers have outages. Wrapping integrations in flags gives you a manual override for when external dependencies go wrong, without needing a deploy during the incident.

Use cases

Gradual rollouts - Start at 5%, watch your error rate and latency, increase to 25%, repeat. By the time you reach 100% you have real-world confidence in the feature.

Premium feature gating - Show advanced functionality only to paying customers. Change the gating rule (free plan, pro plan, enterprise) from the dashboard without a code change.

Scheduled releases - Coordinate a feature launch with a marketing campaign by turning a flag on at a specific time, without needing someone at a keyboard to deploy.

Maintenance mode - Disable a feature that depends on a service being updated, and show a friendly notice instead of an error.

Kill switches - Protect the system during incidents. If a new feature starts degrading performance, turning off its flag is faster than any deployment.

Best practices

Name flags clearly. new-checkout-flow tells you what it controls. flag-123 tells you nothing when you're debugging an incident at midnight.

Keep them short-lived. A flag that's been fully rolled out for six months is just dead code wrapped in an if. Set a reminder when you create a flag to clean it up once the rollout is complete.

Treat flags as code. Review flag additions in pull requests. Document what each flag controls and who owns it. Flags are part of your release logic.

Always have a fallback. The value you set when the flag is off should always be the safe, known-working behaviour - never the new thing.

Avoid flag dependencies. Flags that only work correctly when another flag is also on are a maintenance nightmare. Keep each flag independently meaningful.

Getting started

The fastest path is to pick one low-risk feature and wrap it in a flag. You don't need to retrofit your entire codebase - start with the next feature you build.

For implementation details, see our framework guides:

• Feature flags in JavaScript (any framework)
• Feature flags in React
• Feature flags in Next.js
• Feature flags in Vue
• Feature flags in Node.js

Ready to deploy with confidence? Try Supaship and have your first flag live in minutes. Free forever up to 1M events/month - no credit card required. Pro plan is $30/month for your entire workspace.