Feature Flags: Ship Code Without Shipping Risk

We shipped a checkout redesign to 100% of users on a Friday afternoon. Conversion dropped 12% over the weekend. By Monday morning, we'd lost ₹3.2 lakh in revenue. If we'd had a feature flag, we could have rolled back in 10 seconds instead of waiting for a hotfix deployment. That's the day we adopted feature flags for every significant change.

Types of Feature Flags

Not all flags are the same. Using the wrong type for your use case leads to flag sprawl and technical debt.

Release flags should be temporary — once the feature is fully rolled out, remove the flag. Ops and permission flags are permanent parts of your system. This distinction matters for lifecycle management.

Implementation Patterns

Basic Implementation

// Simple feature flag service
interface FeatureFlags {
  isEnabled(flagName: string, context?: UserContext): boolean;
}

// Usage in application code
function renderCheckout(user: User) {
  if (featureFlags.isEnabled('new-checkout-flow', { userId: user.id })) {
    return renderNewCheckout(user);
  }
  return renderOldCheckout(user);
}

// Usage in API route
app.post('/api/orders', async (req, res) => {
  if (featureFlags.isEnabled('batch-order-processing')) {
    return batchOrderHandler(req, res);
  }
  return singleOrderHandler(req, res);
});

Flag Evaluation Rules

Flags evaluate to true or false based on rules. Common targeting rules:

• Percentage rollout: 10% of all users see the new feature (consistent per user via hash)
• User targeting: Specific users or groups (internal team, beta testers, enterprise customers)
• Attribute targeting: Users in India, users on mobile, users who signed up after a certain date
• Environment: Enabled in staging, disabled in production

Consistent Hashing for Percentage Rollouts

When you set a flag to 10%, the same user should always see the same variant. Don't use Math.random() — use a hash of the user ID:

function isInPercentage(userId: string, flagName: string, percentage: number): boolean {
  // Hash user ID + flag name for consistent assignment
  const hash = murmurhash3(`${flagName}:${userId}`);
  const bucket = hash % 100;
  return bucket < percentage;
}

// User "usr_abc" gets bucket 37 for "new-checkout"
// At 10%: excluded (37 >= 10)
// At 50%: included (37 < 50)
// At 100%: included
// The user's assignment only changes when you change the percentage

Gradual Rollout Strategies

The Safe Rollout Plan

1. 0% → Internal team (dogfooding) — Enable for employees only. Use for 2-3 days. Catch obvious issues
2. 1% → Canary — Real users, minimal blast radius. Monitor error rates, latency, conversion. Run for 24 hours
3. 10% → Early rollout — Statistically significant sample. Compare metrics between flag-on and flag-off cohorts. Run for 2-3 days
4. 50% → Broad rollout — If metrics are good at 10%, expand. This is also where you can run A/B tests for conversion impact
5. 100% → Full rollout — All users. Monitor for 1 week
6. Remove flag — After 1 week at 100% with no issues, delete the flag and the old code path

Tools Comparison

Flag Lifecycle Management

Technical debt from abandoned flags is the #1 complaint we hear. A codebase with 200 stale flags is harder to maintain than one without flags.

Rules We Follow

• Every release flag gets an expiry date. Set it when creating the flag. 30 days after full rollout, the flag must be removed
• Flag cleanup is part of the definition of done. A feature isn't "done" until the flag is removed and the old code path is deleted
• Monthly flag audit. Review all flags older than 30 days. Is it fully rolled out? Remove it. Is it at 50% for 3 months? Make a decision and move on
• Name flags with intent. release-new-checkout-q4-2025 is better than flag-123. When someone sees it in 6 months, they should know what it's for

Common Pitfalls

Frequently Asked Questions