DEV Community: Yanka Santos(She/her)

Feature Flags: The Kill Switch Every Startup Needs

Yanka Santos(She/her) — Fri, 06 Mar 2026 14:01:28 +0000

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();
}

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();
}

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

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

✅ With Feature Flags

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

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

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
);

🔁 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
);

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);

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.

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

Circular Dependencies in Monorepos: The Silent Architecture Killer

Yanka Santos(She/her) — Mon, 16 Feb 2026 13:51:48 +0000

If you've ever worked with an Nx monorepo (especially in a React front-end), chances are you've hit this wall:

"Why is this import causing a circular dependency… and why is my app breaking in the weirdest way possible?"

Recently, I ran into this exact issue while working with a monorepo architecture that looked perfectly reasonable at first glance — until it wasn't. The build failed, the error message was cryptic, and my "perfectly logical" code structure turned out to be a dependency nightmare.

Let me walk you through what happened, why it's dangerous, and how to fix it the right way.

🧩 The Scenario: When Good Architecture Goes Circular

Picture this: you're working with an Nx monorepo with the following structure:

apps/
  web/
libs/
  modules/
    product/
    price/
  shared/
    ui/
    data/

Your modules:

@modules/product - domain logic for products
@modules/price - pricing logic derived from product data
@shared/ui - reusable UI components used across the app

Here's where things went sideways:

The product module needed to access mock data for testing
That mock data lived in the price module (seemed logical at the time)
The price module imported UI components from shared/ui to render pricing displays
The shared/ui module had a ProductCard component that imported types from product

Boom. 💥 Circular dependency detected.

product → price (imports mock data)
    ↓
price → shared/ui (imports UI components)
    ↓
shared/ui → product (imports types and components)
    ↓
    ← → ← (circular!)

Nx caught it. The build failed. And I learned an important lesson about architecture boundaries.

🔄 What Is a Circular Dependency (And Why Should You Care)?

A circular dependency happens when:

Module A depends on Module B
Module B depends on Module C
Module C (directly or indirectly) depends back on Module A

In monorepos, this often happens accidentally because the boundaries between domains, UI, and shared utilities start to blur as the codebase grows.

⚠️ Why This Is Actually Dangerous

Circular dependencies aren't just a linting annoyance. They cause real, production-breaking problems:

❌ Unpredictable Module Initialization

The JavaScript module system can't determine which module to initialize first. Here's what happens:

// product/index.ts
import { priceMocks } from '@modules/price';

export const productData = {
  ...priceMocks.products, // priceMocks might be undefined here!
};

// price/index.ts  
import { ProductCard } from '@shared/ui';

export const priceMocks = {
  products: [...], // This might not be initialized when product imports it
};

Your imports might resolve to undefined, leading to runtime errors that only appear in specific initialization orders—the worst kind of bug to debug.

❌ Broken Tree-Shaking and Bundle Bloat

Bundlers like Webpack and Vite can't properly shake unused code when modules form circular chains. This means:

Larger bundle sizes
Slower load times
Code that should be split across chunks gets bundled together

❌ Testing Nightmares

When modules depend on each other, mocking becomes impossible:

// Trying to test product module
jest.mock('@modules/price'); // But price depends on shared/ui
jest.mock('@shared/ui'); // But shared/ui depends on product
// 🤯 Your test setup becomes a house of cards

❌ Tight Coupling Between Domains

Circular dependencies signal that your domain boundaries are wrong. If product can't exist without price, and price can't exist without product, you don't have separate domains—you have one tangled mess.

Worst of all? These issues compound as your codebase grows. What starts as a simple two-module cycle becomes a web of interdependencies that makes refactoring feel like defusing a bomb.

🧠 The Root Cause (Hint: It's Architecture, Not Just Imports)

After stepping back and analyzing the problem, I realized the real issue:

Shared UI was doing too much.

When a shared/ui module:

Knows about domain data (product, price)
Imports business logic or domain types directly
Exposes data instead of just UI contracts

…it stops being "shared UI" and becomes a dependency trap.

The problem isn't the imports themselves—it's that module boundaries weren't clearly defined. Each module was reaching across domains because there was no clear contract between layers.

✅ The Right Way to Fix It: A Complete Refactoring Guide

Let me show you the actual before and after of how I fixed this issue.

📛 Before: The Circular Dependency

// libs/modules/product/src/index.ts
import { priceMocks } from '@modules/price';

export const useProduct = () => {
  return {
    ...priceMocks.productPrices, // Importing from price module
  };
};

// libs/modules/price/src/index.ts
import { ProductCard } from '@shared/ui';

export const priceMocks = {
  productPrices: [...]
};

export const PriceDisplay = () => (
  <ProductCard /> // Using shared UI
);

// libs/shared/ui/src/components/ProductCard.tsx
import { Product } from '@modules/product'; // Importing from product!

interface ProductCardProps {
  product: Product; // Using product domain type
}

The Problem:

product → price → shared/ui → product (circular!)
Shared UI knows about domain types
Mock data is embedded in feature modules

✅ After: Clean, One-Way Dependencies

Step 1: Extract Shared Types and Data

// libs/shared/data/src/lib/types/product.types.ts
export interface Product {
  id: string;
  name: string;
  description: string;
}

export interface Price {
  productId: string;
  amount: number;
  currency: string;
}

// libs/shared/data/src/lib/mocks/product.mocks.ts
import { Product } from '../types';

export const productMocks: Product[] = [
  { id: '1', name: 'Widget', description: 'A great widget' }
];

// libs/shared/data/src/lib/mocks/price.mocks.ts
import { Price } from '../types';

export const priceMocks: Price[] = [
  { productId: '1', amount: 29.99, currency: 'USD' }
];

Step 2: Make Shared UI Dumb (On Purpose)

// libs/shared/ui/src/components/ProductCard.tsx
// ✅ NO imports from feature modules!

interface ProductCardProps {
  title: string;
  description: string;
  price: string;
  onAddToCart?: () => void;
}

export const ProductCard: React.FC<ProductCardProps> = ({
  title,
  description,
  price,
  onAddToCart
}) => {
  return (
    <div className="product-card">
      <h3>{title}</h3>
      <p>{description}</p>
      <span className="price">{price}</span>
      {onAddToCart && (
        <button onClick={onAddToCart}>Add to Cart</button>
      )}
    </div>
  );
};

Key principle: The UI component receives data via props. It knows nothing about where the data comes from. No domain imports. No business logic. No surprises.

Step 3: Feature Modules Orchestrate, UI Presents

// libs/modules/product/src/lib/containers/ProductContainer.tsx
import { ProductCard } from '@shared/ui';
import { productMocks, priceMocks } from '@shared/data';
import { formatPrice } from './utils';

export const ProductContainer: React.FC<{ productId: string }> = ({ productId }) => {
  const product = productMocks.find(p => p.id === productId);
  const price = priceMocks.find(p => p.productId === productId);

  if (!product) return null;

  return (
    <ProductCard
      title={product.name}
      description={product.description}
      price={formatPrice(price)}
      onAddToCart={() => console.log('Added to cart')}
    />
  );
};

Step 4: Clear Dependency Flow

@shared/data (types, mocks, utilities)
    ↓
@shared/ui (presentation components)
    ↓
@modules/product, @modules/price (domain logic + orchestration)
    ↓
@apps/web (application)

Each layer only imports from layers below it. Never upward.

🛠️ Enforce It with Nx Module Boundaries

Since you're using Nx, you have a superpower: enforceable module boundaries.

Configure Module Boundaries in Your Nx Workspace

// nx.json or .eslintrc.json
{
  "@nx/enforce-module-boundaries": [
    "error",
    {
      "enforceBuildableLibDependency": true,
      "allow": [],
      "depConstraints": [
        {
          "sourceTag": "type:feature",
          "onlyDependOnLibsWithTags": ["type:ui", "type:data", "type:util"]
        },
        {
          "sourceTag": "type:ui",
          "onlyDependOnLibsWithTags": ["type:util", "type:data"]
        },
        {
          "sourceTag": "type:data",
          "onlyDependOnLibsWithTags": ["type:util"]
        },
        {
          "sourceTag": "type:util",
          "onlyDependOnLibsWithTags": []
        }
      ]
    }
  ]
}

Tag Your Libraries

// libs/modules/product/project.json
{
  "tags": ["type:feature", "scope:product"]
}

// libs/shared/ui/project.json
{
  "tags": ["type:ui", "scope:shared"]
}

// libs/shared/data/project.json
{
  "tags": ["type:data", "scope:shared"]
}

Now Nx will prevent you from creating circular dependencies at compile time. If shared/ui tries to import from modules/product, the linter will immediately fail:

✗ A project tagged with "type:ui" can only depend on libs tagged with "type:util", "type:data"

🔍 Detection: Catch Circular Dependencies Before They Ship

1. Use Nx's Built-In Dependency Graph

npx nx graph

This opens a visual graph of your workspace. Circular dependencies will be highlighted in red.

2. Add Madge for CI/CD Checks

npm install -D madge

# Add to package.json scripts
"check:circular": "madge --circular --extensions ts,tsx libs/"

Add this to your CI pipeline:

# .github/workflows/ci.yml
- name: Check for circular dependencies
  run: npm run check:circular

3. ESLint Plugin for Immediate Feedback

npm install -D eslint-plugin-import

// .eslintrc.json
{
  "plugins": ["import"],
  "rules": {
    "import/no-cycle": ["error", { "maxDepth": 2, "ignoreExternal": true }]
  }
}

Your IDE will now warn you as you type when you create a circular import.

🧠 The Mental Model Shift

Here's the key mindset change that helped me:

Don't ask: "What feature does this code belong to?"

Ask instead:

"What does this code depend on?"
"What should be allowed to depend on this code?"
"If I delete this module, what breaks?"

Think of your architecture like a building:

Foundation (shared/data, shared/util): The base that everything rests on
Floors (shared/ui): Built on the foundation, used by everyone
Rooms (feature modules): Built on the floors, can't support each other
Roof (apps): Sits on top, depends on everything below

A room can't hold up another room. That's not how buildings work.

🎯 Practical Rules to Live By

1️⃣ Shared UI Should Be Dumb

A good shared/ui component:

✅ Receives data via props
✅ Has no idea where data comes from
✅ Could be published as an npm package tomorrow
❌ Never imports from feature modules
❌ Contains no business logic

Think of it like Material-UI or Chakra—it renders what you give it, period.

2️⃣ Feature Modules Should Never Import Each Other

If product needs something from price, that "something" belongs in shared/data.

// ❌ Bad
import { calculateDiscount } from '@modules/price';

// ✅ Good
import { calculateDiscount } from '@shared/data';

3️⃣ Types and Interfaces Belong in Shared Layers

If more than one module needs a type, it's shared by definition:

// ❌ Bad - defined in feature module
// libs/modules/product/src/types.ts
export interface Product { ... }

// ✅ Good - defined in shared layer
// libs/shared/data/src/types/product.types.ts
export interface Product { ... }

4️⃣ Mocks Don't Live in Production Code

Move mocks out of src/ folders:

libs/
  modules/
    product/
      src/              ← Production code
      __mocks__/        ← Mocks for testing
      __storybook__/    ← Storybook-specific mocks

Or better yet, centralize them in shared/data/mocks/.

5️⃣ One Direction: Dependencies Flow Downward

Apps ────────────┐
                 ↓
Feature Modules ─┤
                 ↓
Shared UI ───────┤
                 ↓
Shared Data ─────┤
                 ↓
Shared Utils ────┘

If you ever find yourself making an import that goes upward, stop. That's your architectural red flag.

⚠️ When Circular Dependencies Are (Kinda) OK

Exception: Type-Only Imports

TypeScript's import type doesn't create runtime circular dependencies:

import type { Product } from '@modules/product';

// This is safe because types are erased at compile time
export interface Price {
  product: Product;
}

However, I still recommend avoiding this. Even if it's technically safe, it creates mental coupling and makes refactoring harder. Better to keep types in shared layers.

📊 Real-World Impact: What Changed After the Fix

After refactoring to eliminate circular dependencies in our monorepo, we saw:

✅ Build time decreased by 23% (from 45s to 35s)
✅ Bundle size reduced by 18% (tree-shaking finally worked)
✅ Test setup simplified (no more circular mock hell)
✅ Onboarding improved (new devs could understand module boundaries)
✅ Zero circular dependency errors for 6 months and counting

The best part? When we added new features, the clear boundaries made it obvious where code should live. No more "where should I put this?" debates.

🎬 Conclusion

Circular dependencies in monorepos aren't just a technical nuisance—they're architecture feedback. When you see one, don't just "fix the import." Step back and ask:

"Why do these modules know so much about each other?"

Your codebase is asking for clearer boundaries. Listen to it.

By:

Extracting shared concerns to dedicated layers
Making UI components presentation-only
Enforcing module boundaries with Nx
Detecting violations early with tooling

…you create a monorepo that's not just buildable, but maintainable, scalable, and actually enjoyable to work in.

The next time you're tempted to make that "quick import" that completes the circle, pause. Your future self (and your team) will thank you.

🛠️ Quick Reference: Nx Circular Dependency Fix Checklist

[ ] Run nx graph to visualize your dependency graph
[ ] Create @shared/data library for types and mocks
[ ] Move all shared types from feature modules to @shared/data
[ ] Refactor @shared/ui components to be prop-based (no domain imports)
[ ] Configure Nx module boundary rules with tags
[ ] Add import/no-cycle ESLint rule
[ ] Set up madge in CI pipeline
[ ] Update team documentation with dependency rules
[ ] Add architectural decision record (ADR) explaining the approach

Have you battled circular dependencies in your Nx monorepo? What strategies worked (or didn't work) for you? I'd love to hear your war stories in the comments! 💬

Nx #Monorepo #React #SoftwareArchitecture #CleanCode #Frontend #TypeScript #WebDevelopment #SoftwareEngineering