Feature Flags in Python: Deploy Code That Doesn't Run Yet

Feature flags let you deploy code that doesn't run yet. That sounds backwards, but it’s the entire point. You merge unfinished features into production, turn them off by default, and flip the switch when you're ready. No more long-lived branches. No more merging nightmares. Just clean, incremental delivery.

The Problem With Feature Branches

Most teams default to feature branches. Create a branch, code for two weeks, merge, pray. That model is fragile. Long-lived branches diverge from mainline code, conflicts pile up, and integration becomes a high-stakes event. Even with CI/CD, merging a two-week branch is a risk—especially if someone else merged something that changed the same lines.

Feature flags invert this. You branch in code, not in git. The flag lives in production alongside everything else. You can build a small piece of a feature, ship it behind a flag, and iterate without ever leaving main.

How Feature Flags Create Safety

The core superpower is decoupling deployment from release. Deploying is the technical act of putting code on servers. Releasing is making that code visible to users. Feature flags let you do them separately.

• Instant rollback: If something breaks, you toggle a flag off. No redeploy, no git revert, no migration rollback. The code stays, but the behavior disappears.
• Targeted exposure: Release a feature to 10% of users first. Monitor errors. Then ramp to 50%. Then 100%. If a bug surfaces in the first wave, only a small cohort sees it.
• A/B testing: Flags are the infrastructure for experiments. Compare a new checkout flow against the old one, with clear metrics.

Beyond Release Toggles

Feature flags aren't just for big launches. They're useful at every scale.

• Kill switches: Every API endpoint you don't fully trust should have a flag. If a third-party service goes down and your code would error, just turn off the path that calls it.
• Operational flags: Need to run a slow migration or database backfill? Wrap it in a flag so you can pause it if production starts struggling.
• Internal early access: Let your own team test a feature before it hits users. Catch UX issues and edge cases before public release.

Common Pitfalls

Feature flags aren't free. They add complexity, and if you manage them poorly, you'll pay for it.

Flag debt is the biggest trap. You ship a feature, everyone celebrates, and the flag stays in the codebase for months. Dead flags add conditionals, make code harder to read, and slow down every deployment. Kill them as soon as the feature is fully rolled out.

Race conditions from flags evaluated at different times. If one service sees the flag as true and another sees it as false, you can get partial states. Use a single source of truth for flag evaluation—usually a centralized service like LaunchDarkly, Split, or even a simple Redis-backed flag store.

Testing complexity. You now have to test every feature with every flag state. That's N configurations for M features. Don't brute-force test every combination. Instead, test the flag evaluation logic separately, and integration-test each state your app actually uses in production.

Practical Implementation

Start simple. No SaaS tool required for a small team.

# A minimal feature flag in Python
import os

FEATURE_FLAGS = {
    "new_checkout": os.getenv("NEW_CHECKOUT_ENABLED", "false").lower() == "true"
}

if FEATURE_FLAGS["new_checkout"]:
    handle_checkout_v2()
else:
    handle_checkout_v1()

That's it. You can toggle it with an environment variable. For more control, use a simple JSON file you can update at runtime without a redeploy.

import json

def is_enabled(flag_name):
    with open("flags.json") as f:
        flags = json.load(f)
    return flags.get(flag_name, False)

For production at scale, use a dedicated service. They handle caching, gradual rollouts, user targeting, and audit logs.

The Real Win

Feature flags turn deployment from an event into a background process. You don't need a "deploy day" or a release manager. You push code continuously, and when stakeholders decide a feature is ready, you toggle a flag. No stress. No all-nighters.

The teams that use them well ship faster, break less often, and recover instantly. That's not a secret weapon—it's just a better way to work.