DEV Community

Cover image for Feature Flags: The Kill Switch Every Startup Needs
Yanka Santos(She/her)
Yanka Santos(She/her)

Posted on

Feature Flags: The Kill Switch Every Startup Needs

#featureflags #openfeature #launchdarkly #software

For frontend, backend & platform engineers at fintech and gaming startups · 12 min read

You're shipping a new payment flow on Black Friday. Or rolling out a new loot-box mechanic to 2 million players simultaneously. One bug and it's all over. Feature flags are the safety net, the telescope, and the scalpel — all in one.

Let's be direct: if you're working at a fintech or gaming startup and you're not using feature flags, you're flying blind at altitude. You're deploying code and hoping for the best — and hope is not a release strategy.

This post covers what feature flags actually are (and what they're not), how they differ from feature toggles, and how to implement them in production using OpenFeature and LaunchDarkly — the modern standard for flag management at scale.

What Is a Feature Flag?

A feature flag (also called a feature gate, feature switch, or feature control) is a software mechanism that allows you to enable or disable functionality at runtime — without deploying new code.

Think of it as a conditional in your codebase that's controlled externally.

Before flags:

// You either ship the feature or you don't
if (true) {
  renderNewCheckoutFlow();
}
Enter fullscreen mode Exit fullscreen mode

With flags:

// The flag value comes from an external system — no redeploy needed
const showNewCheckout = await client.getBooleanValue('new-checkout-flow', false);

if (showNewCheckout) {
  renderNewCheckoutFlow();
} else {
  renderLegacyCheckoutFlow();
}
Enter fullscreen mode Exit fullscreen mode

That flag value — new-checkout-flow — can be toggled on or off via a dashboard, pushed to a specific user segment, rolled out to 5% of traffic, or locked to a certain geography. All without touching your codebase.

💡 Real-World Example: Stripe uses feature flags to test new payment APIs with a subset of merchants before full rollout. Riot Games uses them to enable experimental gameplay mechanics on specific servers before global release. The pattern is the same — controlled exposure, at scale.

Feature Flag Evaluation Flow 

 User Request  ──→  SDK / Client  ──→  Flag Evaluation
                                             │
                                     ┌───────┴────────┐
                                     │   Flag ON?     │
                                     │   Segment?     │
                                     │   Rollout %?   │
                                     └───────┬────────┘
                                    ┌────────┴─────────┐
                                   YES                  NO
                                    │                   │
                             ┌──────┴──────┐   ┌───────┴──────┐
                             │ New Feature │   │ Legacy Code  │
                             └──────┬──────┘   └───────┬──────┘
                                    │                   │
                             📊 Track Metrics   📊 Track Metrics
                                    │                   │
                             └──────┴───────────────────┘
                                          │
                              Aggregate → Decide → Ship or Kill
Enter fullscreen mode Exit fullscreen mode

Feature Flag vs Feature Toggle: Not the Same Thing

This is where most engineers get fuzzy. The terms are often used interchangeably — but there's a meaningful difference in intent and lifecycle.

Feature Toggle Feature Flag
Lifespan Short-lived Long-lived
Location Inside the codebase External service / config
Purpose Hide incomplete work during development Experimentation, ops control, segmentation
Removed after ship? Yes Not necessarily (some are permanent)
Dashboard needed? No Yes
Supports A/B testing? No Yes

"A feature toggle says 'not yet'. A feature flag says 'for you, yes — for everyone else, not yet.'"

The 4 Types of Feature Flags You'll Actually Use

🚀 Release Flags

Deploy code to production but keep it dark. Enable for specific users or a percentage of traffic. Classic for canary deployments.

🧪 Experiment Flags

A/B and multivariate testing. Show variant A to 50% of users, variant B to the other 50%. Measure, decide, ship the winner.

🔌 Ops Flags

Kill switches for your infrastructure. Disable a third-party payment provider in real-time if it starts failing. Essential for fintechs.

💼 Permission Flags

Control access to features by plan tier, region, or user attribute. Enterprise-only dashboard? Beta access for power users? This is it.

Why This Matters for Fintech & Gaming

These two verticals share something critical: the cost of a bad deploy is catastrophic and immediate.

In fintech, a broken payment flow means lost revenue, chargebacks, and regulatory risk — every minute counts. In gaming, a bugged ability or a broken economy mechanic at launch can spiral into player outrage and press coverage within hours.

Incident Timeline: With vs. Without Flags

❌ Without Feature Flags

Deploy ──→ Bug Found ──→ Hotfix Dev ──→ CI/CD Pipeline ──→ Redeploy
                                                                │
                                              ⏱ 30 min – 4 hours of exposure
Enter fullscreen mode Exit fullscreen mode

✅ With Feature Flags

Deploy ──→ Bug Found ──→ Toggle Flag OFF ──→ Fix in peace
                               │
                ⏱ 30 seconds to mitigate. Zero redeploy needed.
Enter fullscreen mode Exit fullscreen mode

OpenFeature: The Vendor-Neutral Standard

Before OpenFeature, every feature flag provider had its own SDK. Switch from LaunchDarkly to Unleash? Rewrite all your flag evaluation code. It was vendor lock-in by design.

OpenFeature is a CNCF incubating project that defines a vendor-neutral, open standard API for feature flagging. You code against the OpenFeature API — and swap providers via a plugin with zero application code changes.

OpenFeature Architecture 

┌─────────────────────────────────────────────────────────────┐
│                     Your Application                        │
│              (calls OpenFeature SDK only)                   │
└────────────────────────┬────────────────────────────────────┘
                         │  Standard API
┌────────────────────────▼────────────────────────────────────┐
│                   OpenFeature SDK                           │
│          (Node.js / Go / Java / Python / .NET)              │
└────────────────────────┬────────────────────────────────────┘
                         │  Provider Interface
┌────────────────────────▼────────────────────────────────────┐
│              Provider Plugin (your choice)                  │
│    LaunchDarkly │ Unleash │ Flagsmith │ CloudBees │ ...      │
└─────────────────────────────────────────────────────────────┘

  Swap the provider → zero application code changes
Enter fullscreen mode Exit fullscreen mode

Setting Up OpenFeature with LaunchDarkly (Node.js) 

// 1. Install dependencies
// npm install @openfeature/server-sdk @openfeature/launchdarkly-provider

import { OpenFeature } from '@openfeature/server-sdk';
import { LaunchDarklyProvider } from '@openfeature/launchdarkly-provider';

// 2. Register your provider once at startup
await OpenFeature.setProviderAndWait(
  new LaunchDarklyProvider('YOUR_SDK_KEY')
);

// 3. Get a client
const client = OpenFeature.getClient();

// 4. Evaluate a flag
const isNewCheckoutEnabled = await client.getBooleanValue(
  'new-checkout-flow',
  false,                     // default if flag not found
  { targetingKey: user.id }  // evaluation context
);
Enter fullscreen mode Exit fullscreen mode

🔁 Switching Providers: Tomorrow you decide to move from LaunchDarkly to Unleash. You change one line — the provider registration. Every getBooleanValue(), getStringValue(), and getNumberValue() call across your entire codebase stays exactly the same.

LaunchDarkly: The Provider

LaunchDarkly is the battle-tested flag management platform used by Atlassian, IBM, and hundreds of fintechs and game studios. It handles targeting rules, percentage rollouts, A/B experiments, scheduled flags, and more — all from a dashboard your PMs can also operate.

Advanced: Targeting Rules for Gaming 

// Rich evaluation context for player segmentation
const evaluationContext = {
  kind: 'multi',
  user: {
    key: player.id,
    country: player.country,        // 'US', 'DE', 'BR'
    level: player.level,            // 42
    plan: player.subscriptionTier,  // 'free' | 'premium'
    betaAccess: player.isBetaTester,
  },
  game: {
    key: session.gameId,
    region: session.server,         // 'EU-WEST', 'NA-EAST'
    matchType: session.mode,        // 'ranked' | 'casual'
  }
};

// This flag only enables for premium EU players above level 30
// — configured entirely in the LaunchDarkly dashboard
const showNewAbility = await client.getBooleanValue(
  'hero-new-ultimate-ability',
  false,
  evaluationContext
);
Enter fullscreen mode Exit fullscreen mode

Fintech Example: Payment Provider Fallback (Ops Flag) 

// Ops flag: switch payment processors without a deploy
const activeProcessor = await client.getStringValue(
  'active-payment-processor',
  'stripe',                      // default to Stripe
  { targetingKey: merchant.id, region: merchant.region }
);

const processorMap = {
  'stripe':     StripeGateway,
  'adyen':      AdyenGateway,
  'braintree':  BraintreeGateway,
};

const gateway = processorMap[activeProcessor] ?? StripeGateway;
await gateway.processPayment(order);
Enter fullscreen mode Exit fullscreen mode

If Stripe starts degrading? Log into LaunchDarkly, flip active-payment-processor to 'adyen'. Done. No deploy, no 3am incident call.

The Progressive Rollout Pattern

The real power of feature flags isn't just on/off — it's the ability to progressively increase exposure while monitoring metrics in real time.

Rollout Stages 

Stage 1 — Internal Dogfooding
  ████░░░░░░░░░░░░░░░░░░░░░░░░░░  ~team only
  Enable for engineering & QA. Test in production with real data.

Stage 2 — Beta Segment (1–5%)
  ████████░░░░░░░░░░░░░░░░░░░░░░  1-5%
  Opted-in beta users or random sample. Monitor errors + KPIs.

Stage 3 — Canary Release (10–20%)
  ████████████████░░░░░░░░░░░░░░  10-20%
  Increase gradually. Auto-kill if error rate spikes.

Stage 4 — Staged Rollout (50%)
  ████████████████████████░░░░░░  50%
  Half your users. Confident in metrics? Keep going.

Stage 5 — Full Release (100%)
  ██████████████████████████████  100% ✓
  Ship to everyone. Monitor 24-48h. Then clean up the flag.
Enter fullscreen mode Exit fullscreen mode

The 5-Step Rollout Playbook

01 — Internal Dogfooding 0% → team
Enable the flag only for your engineering and QA team. Test in production with real data, no real user impact.

02 — Beta Segment team → 1–5%
Roll out to opted-in beta users or a randomly sampled cohort. Monitor error rates, latency, and core KPIs.

03 — Canary Release 5% → 20% → 50%
Gradually increase the percentage. Automate metric monitoring — if error rate spikes above threshold, auto-kill the flag.

04 — Full Rollout 50% → 100%
Ship to everyone. Monitor for 24–48h. Then remove the flag from code and clean up the technical debt.

05 — Cleanup 100% → archived
Don't let dead flags accumulate. Archive or delete from your provider, and remove the conditional from code. Flag debt is real.

Dos and Don'ts

✅ Do This

  • Name flags semantically: checkout-v2-enabled, payment-fallback-adyen
  • Always provide a sensible default value (fail safe)
  • Add flag owners and expiry dates in your provider dashboard
  • Track flag evaluations as telemetry / observability signals
  • Clean up flags after 100% rollout — schedule it as a ticket
  • Use evaluation context for rich targeting (user tier, region, plan)
  • Cache flag values client-side to avoid latency on every request

❌ Avoid This

  • Nesting flags inside other flags (impossible to reason about)
  • Using flags for secrets or sensitive configuration
  • Letting old flags accumulate — "flag debt" slows teams down
  • Hardcoding flag names as magic strings scattered everywhere (use constants)
  • Skipping the cleanup phase post-rollout
  • Blocking UI render on asynchronous flag evaluation

TL;DR

  • Feature flags let you control feature exposure at runtime, without code deploys
  • Feature toggles are short-lived code conditionals; feature flags are long-lived, externally managed controls
  • Use release, experiment, ops, and permission flag types for different use cases
  • OpenFeature is the vendor-neutral SDK standard — code once, swap providers freely
  • LaunchDarkly gives you targeting rules, percentage rollouts, and a PM-friendly dashboard
  • Progressive rollout (team → 1% → 20% → 100%) is the safest path to production
  • For fintechs: ops flags are your circuit breaker
  • For gaming studios: release flags are your launch control panel
  • Flag debt is real — always schedule cleanup after full rollout

Tags: #featureflags #openfeature #launchdarkly #fintech #gamedev #devops #engineering

Top comments (0)