Feature Flags in SaaS: Safe Deploys with Progressive Rollouts

Shipping code to production is the moment where confidence meets reality. Feature flags let you separate deployment from release — you push code to production without activating it for users, then roll it out progressively while watching metrics. When something breaks, you flip a switch instead of rolling back a deployment.

This is the operational pattern that Spotify, Netflix, and GitHub use to ship dozens of times per day without bringing down their platforms. Here's how it works and how to build it into your SaaS.

What Are Feature Flags?

A feature flag (also called a feature toggle or feature switch) is a conditional that wraps a code path. When the flag is OFF, the old code path runs. When the flag is ON, the new code runs. The flag state is controlled externally — via a UI or API — without redeploying.

const useNewCheckoutFlow = await featureFlags.isEnabled('new_checkout', userId);

if (useNewCheckoutFlow) {
  return renderNewCheckout();
} else {
  return renderLegacyCheckout();
}

This simple pattern unlocks several capabilities: gradual rollout to a percentage of users, A/B testing, kill switches, beta user programs, and time-based releases.

Types of Feature Flags

Release flags are short-lived flags that control whether new code is active. They're created when a feature is in development, turned on during rollout, and deleted once the feature is stable. The lifecycle is typically days to weeks.

Experiment flags power A/B tests. Rather than binary on/off, they route users to one of several variants. Metrics are collected per variant to determine which performs better. These flags live for the duration of the experiment.

Ops flags (kill switches) control operational behavior — rate limiting, circuit breakers, fallback paths. They're built for speed: if a service degrades, you flip the flag to route around the problem. These often live permanently.

Permission flags gate features by user plan, role, or cohort. Beta features might be ON only for Pro plan users — this is how SaaS products implement plan-based feature gating without scattered conditional logic.

Progressive Rollout Strategies

Percentage-based rollout: Enable a feature for X% of users, watch error rates and key metrics, then increment. Start at 1%, then 5%, 10%, 25%, 50%, 100%. Each step is a data point.

Cohort-based rollout: Enable for a specific user segment first — beta users, users in a specific geographic region, users who signed up within a date range, or users on a specific plan.

Canary deployment: Route a percentage of traffic to the new version at the infrastructure level. Feature flags operate at the application layer — both can be combined for defense-in-depth.

Dark launch: Send real production traffic to the new code path but don't show results to users. This tests performance and correctness under real load without affecting the user experience.

Feature Flag Tools Compared

Tool	Best For	Pricing	Self-Hosted?
LaunchDarkly	Enterprise, complex targeting	$$$	No
Flagsmith	Open-source teams, cost control	Free / $	Yes
Unleash	Self-hosted enterprise	Free / $$	Yes
Split.io	Experiment-focused teams	$$	No
GrowthBook	Stats-powered A/B testing	Free / $	Yes
Flipt	Simple, gRPC-native	Free	Yes

For early-stage SaaS, Flagsmith or GrowthBook self-hosted is the right call — no per-seat licensing costs while validating. At scale, LaunchDarkly's targeting granularity and multi-language SDKs become worth the cost.

Implementation Pattern

A minimal feature flag service needs:

1. A flag store
   A database or config store that maps flag names to state and targeting rules.
2. An evaluation engine
   Logic that takes a flag name and user context, and returns true/false.
3. An SDK or client
   Your application code calls the SDK, which evaluates flags and caches results per request.
4. A management UI
   Where your team enables/disables flags and configures targeting rules.

# Minimal flag evaluation with Redis
def is_enabled(flag_name: str, user_id: str) -> bool:
    flag = redis.hgetall(f'flag:{flag_name}')
    if not flag or flag['status'] == 'off':
        return False
    if flag['status'] == 'on':
        return True
    # Percentage rollout
    threshold = int(flag['percentage'])
    user_bucket = int(hashlib.md5(f'{flag_name}:{user_id}'.encode()).hexdigest(), 16) % 100
    return user_bucket < threshold

Rollout Observability

A feature flag without metrics is a switch in the dark. For every flag rollout, instrument:

• Error rate by flag variant (old vs new code path)
• Latency by variant (is the new code slower?)
• Business metric you care about (conversion rate, API success rate, page load time)

Set up alerts so that if the error rate for the new variant exceeds the control group by more than a threshold, you're paged immediately and can flip the flag back.

Common Mistakes

• Flag sprawl: Teams create flags and never delete them. After a year, nobody knows which flags are active or dead code. Establish a flag lifecycle process — owner, review date, delete-by date.
• Flags wrapping flags: Nesting conditional flag checks creates combinatorial state that's impossible to reason about. One feature = one flag.
• No default values: If the flag service goes down, what does your app do? Always define a safe default and test the failure mode.
• Evaluating flags in tight loops: Cache flag state per request context. Never evaluate flags inside database query loops.

Related: Managing Secrets in CI/CD: Best Practices

FAQs

What is the difference between a feature flag and a feature toggle?

They're the same thing — different names for the same pattern. "Feature flag," "feature toggle," and "feature switch" are used interchangeably. The underlying concept is identical: a runtime conditional that controls code path activation without a redeployment.

Should feature flags live in code or in a database?

Both. The flag definition and default value live in code. The runtime override — state, targeting rules, and rollout percentage — lives in an external service or database. This ensures the application always has a fallback even if the flag service is unavailable.

How do you clean up old feature flags?

Establish a flag lifecycle policy: every flag has an owner and a review date. When rollout reaches 100% and the feature is stable for two sprints, the flag is removed and the old code path deleted. Use static analysis to find flag references in code and audit them in each sprint review.

Can feature flags be used for A/B testing?

Yes, but experiment flags differ from release flags. Experiment flags need consistent variant assignment per user, statistical significance tracking, and metric segmentation per variant. Tools like GrowthBook and Split are designed specifically for this use case.