Feature Flag

What Is a Feature Flag

A feature flag (also called a feature toggle) is a conditional statement wrapped around a piece of code that controls whether that code runs. Instead of shipping a feature to everyone the moment it's merged, engineers wrap it in a flag and decide later, often in real time, who sees it. The flag's state (on, off, or targeted to a subset of users) is usually controlled through a dashboard, not a code change.

At its simplest, a feature flag looks like this in code:

if (flags.isEnabled('new-checkout-flow', user)) {
  renderNewCheckout();
} else {
  renderOldCheckout();
}

The logic for isEnabled can be as simple as a boolean in a config file, or as sophisticated as a rules engine that checks user ID, plan tier, geography, or random percentage rollout.

Why Feature Flags Matter for Early-Stage Founders

For a small team shipping fast, feature flags decouple two things that are normally tangled together: deploying code and releasing a feature. This separation matters a lot at the early stage:

• Ship unfinished work safely. Merge code to main daily, even if the feature isn't done, without exposing it to users. This avoids long-lived branches and painful merge conflicts.
• De-risk launches. Roll a new feature out to 5% of users first. If something breaks, flip the flag off instantly instead of scrambling to roll back a deploy.
• Test with real users before a full launch. Show a new onboarding flow to beta users or a specific cohort while everyone else sees the stable version.
• Sell before you build fully. Enable a flag for a single enterprise prospect during a sales demo, even if the feature isn't ready for the general product.
• Kill a broken feature in seconds. If a new integration starts throwing errors, toggle it off without waiting for an emergency deploy.

For teams doing rapid launches on tight timelines, this is often the difference between a bad bug lasting five minutes versus five hours.

How Feature Flags Work in Practice

Most teams use one of three approaches, roughly in order of maturity:

1. Hardcoded config flags. A boolean in an environment variable or config file. Simple, but requires a redeploy to change, which defeats part of the purpose.
2. Database-backed flags. A flags table that the app checks at runtime. Cheap to build, works for small teams, but lacks targeting rules and audit history.
3. Dedicated feature flag platforms. Tools like LaunchDarkly, Statsig, Unleash, or PostHog's feature flags give you percentage rollouts, user targeting, scheduling, and analytics integration out of the box.

A typical rollout sequence looks like this:

• Day 1: Flag created, off for everyone except the internal team.
• Day 3: Flag enabled for 5% of users, monitored for errors and support tickets.
• Day 7: No issues found, expand to 25%, then 100% over the following week.
• Day 21: Flag removed from code entirely once the feature is stable and permanent.

That last step is important and often skipped.

Common Mistakes

Never cleaning up old flags. Flags are meant to be temporary. A codebase with hundreds of stale flags from features shipped a year ago becomes a nightmare to reason about and debug. Set a review cadence (monthly is common) to delete flags for features that are now fully rolled out or fully killed.

Using flags as a substitute for testing. A flag lets you turn a feature off fast, but it doesn't replace QA. Teams sometimes ship untested code because "we can just flag it off if it breaks," which still means real users hit real bugs first.

Flag interaction bugs. When you have multiple flags active at once, some combinations of on/off states may never have been tested together. This is a common source of production incidents at companies with dozens of active flags.

No ownership. Every flag should have a named owner and an expiration date noted at creation. Without this, flags outlive the person who understands why they exist.

Conflating flags with A/B tests. A feature flag controls visibility; an A/B test measures impact. You can use a flag to power an A/B test (showing variant A to one group and variant B to another), but not every flag is an experiment, and not every experiment needs a flag if it's run through a dedicated testing tool.

A Simple Benchmark

There's no universal "correct" number of active flags, but as a rough guide: teams under 10 engineers typically manage 10 to 30 active flags comfortably with a lightweight in-house system. Beyond that, most teams find a dedicated flagging tool pays for itself in reduced incident time and faster iteration, especially when running frequent launches or staged rollouts through a process like the one welaunch.sh helps founders plan.