What Is a Feature Flag? Explained for Beginners

A feature flag is a switch in your code that decides whether a feature runs, checked at runtime instead of decided at build time. Instead of deploying new code to turn a feature on, you flip a flag — usually through a dashboard or config — and the behavior changes instantly, for some or all users.

The Problem Feature Flags Solve

Without flags, "ship a feature" and "deploy code" are the same event. That coupling causes real problems:

• You can't release a half-finished feature to production code without it being visible to users
• Rolling back a bad feature means rolling back a deployment — including any unrelated fixes that shipped alongside it
• You can't test a risky change on 5% of users before going to 100%

Feature flags decouple "the code exists in production" from "the feature is active."

A Simple Example

# Without a feature flag — the only way to disable this is a new deploy
def checkout(cart):
    apply_loyalty_discount(cart)
    return process_payment(cart)
 
# With a feature flag
def checkout(cart):
    if feature_flags.is_enabled("loyalty_discount", user=cart.user):
        apply_loyalty_discount(cart)
    return process_payment(cart)

Now loyalty_discount can be turned on or off for specific users, percentages of traffic, or everyone — without touching the deployment pipeline.

Types of Feature Flags

Release flags — temporary, used to gradually roll out a new feature. Removed once the feature is fully launched.

Ops flags — control operational behavior, like a "kill switch" for a flaky third-party integration. Often permanent.

if feature_flags.is_enabled("recommendation_engine"):
    return get_ai_recommendations(user)
else:
    return get_default_recommendations(user)  # fallback if the AI service is down

Experiment flags — power A/B tests, routing different users to different code paths to measure impact.

Permission flags — control access by user tier, e.g. enterprise-only features.

How Targeting Actually Works

A flag isn't just on/off globally — most flag systems let you target by rules:

{
  "flag": "new_dashboard",
  "rules": [
    { "if": "user.email ends_with '@yourcompany.com'", "serve": true },
    { "if": "user.signup_date > '2026-01-01'", "serve": true, "rollout": "25%" },
    { "default": false }
  ]
}

This lets your own team test in production first, then gradually expand to real users while watching error rates and metrics.

Where Flags Live

You can build flags with a simple config file and database table for small projects, or use a dedicated service for anything beyond basic on/off switches:

• Self-hosted/open source: Unleash, Flagsmith
• Managed services: LaunchDarkly, Split.io, PostHog feature flags

# Using a managed flag service (LaunchDarkly-style SDK pattern)
from ldclient import get as ld_client
 
def checkout(cart):
    client = ld_client()
    context = {"key": cart.user.id, "email": cart.user.email}
    if client.variation("loyalty-discount", context, False):
        apply_loyalty_discount(cart)
    return process_payment(cart)

The Catch: Flag Debt

Flags that never get removed turn into permanent if branches scattered through your codebase. Six months later nobody remembers what legacy_checkout_v2 does or whether it's safe to delete.

The practical discipline:

• Every release flag gets a removal date or a tracked ticket when created
• Run a quarterly audit — list all flags, their current state, and whether anyone still references the "off" branch
• Once a flag has been at 100% for a month with no issues, remove the conditional and delete the flag

# A flag audit is just a grep away from being honest about your debt
grep -rn "feature_flags.is_enabled" --include="*.py" . | wc -l

If that number is growing every sprint and never shrinking, your flags are accumulating as debt, not enabling safer releases.

Why DevOps Engineers Should Care

Feature flags shift risk management from "be very careful during deploys" to "deploy constantly, control exposure separately." This is foundational to continuous deployment — many teams that deploy to production dozens of times a day rely on flags to keep that safe, since the deploy itself becomes low-risk when the actual feature exposure is controlled separately.

Related: What Is Progressive Delivery — Explained