Feature Flags Fundamentals

What a feature flag actually is

A feature flag is a conditional in your code whose value is controlled from outside the deployed artifact. Instead of if (true) baked into a release, you write if (flags.isEnabled("new-checkout")) and decide the answer at runtime. That one indirection is the whole idea, and everything else in this course builds on it.

The plainest possible version looks like this:

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

The code for both paths ships in the same build. Which path a given user hits is a decision you make later, without touching the deploy pipeline. For a deeper first principles walkthrough, the blog post what is a feature flag covers the same ground with more examples.

You will also hear the term “feature toggle.” It means the same thing. The naming split is historical - Martin Fowler’s team popularized “toggle,” while most vendors settled on “flag.” If the vocabulary trips you up, feature flags vs feature toggles untangles it. Throughout this course I use “flag.”

The one insight that makes flags worth it

The reason feature flags matter is not the if statement. It is what the if statement lets you separate: deployment and release.

Without flags those two events are welded together. The moment your code reaches production servers, it is live for every user. That coupling is the source of a surprising amount of engineering pain. Big risky merges pile up because nobody wants to ship half a feature. Releases get scheduled for 2am so a rollback has fewer witnesses. A bug in one feature forces a full redeploy to fix.

With flags, deploying code and turning it on become two independent actions. You can merge unfinished work to main behind a flag that is off, deploy it a dozen times, and flip it on for real users only when it is ready. This is the mechanism that makes trunk based development practical at scale, and it is why the fundamentals here reappear in every later chapter.

Concretely, decoupling buys you four things:

• Ship incomplete work safely. Merge to main daily, keep the flag off, avoid long lived branches that rot and conflict.
• Instant rollback. When something breaks, flip the flag rather than reverting a commit and waiting on a build. Seconds, not minutes.
• Release on a human schedule. Deploy on Tuesday, announce on Thursday, at a calm hour, decoupled from the deploy queue.
• Test in production, carefully. Turn a feature on for yourself or your team only, and validate against real data before anyone else sees it.

How an evaluation actually happens

It helps to picture the moving parts. A flag system has three:

1. A management plane where someone defines the flag and its rules. In a managed tool this is a web dashboard.
2. An SDK embedded in your application that knows the current rules.
3. An evaluation - the moment your code asks “is this flag on for this user?” and gets an answer.

The important design detail is where evaluation happens. Naive implementations call a remote API on every request, which adds network latency to your hot path and makes the flag service a single point of failure. Good platforms avoid this. The SDK opens a streaming connection, pulls the full rule set into memory, and evaluates every flag locally in microseconds. Rule changes are pushed down the stream within a second or two, so the local copy stays fresh without per request calls.

This is why the answer to “will flags slow me down” is almost always no. The latency lives in an initial sync at startup, not in each evaluation. Unleash and ConfigCat both document this local evaluation model explicitly, and it is the default in LaunchDarkly and Flagsmith as well.

Evaluation also takes a context - typically the current user plus attributes like plan tier, country, or signup date. The flag’s rules run against that context to produce a value. In chapter three we get deep into how those rules drive targeting and gradual rollouts. For now, just hold the shape in your head: context in, flag value out, decided at runtime.

A minimal flag, end to end

You do not need a vendor to feel the benefit. Here is a flag with zero dependencies:

const flags = {
  "new-checkout": process.env.FLAG_NEW_CHECKOUT === "true",
};

export function isEnabled(name) {
  return flags[name] === true;
}

Flip the env var, restart, and the feature changes without a code change. That is a real, if crude, feature flag. It already gives you the deploy versus release split.

What it does not give you is targeting (only some users), percentage rollouts, an audit trail, or a UI a product manager can touch without SSHing into a box. Those gaps are exactly what managed platforms fill, and they are the reason most teams graduate from homemade booleans. When you are ready to wire in a real SDK, how to implement feature flags walks through a production setup, and feature flags best practices covers the habits that keep a growing flag inventory from turning into a swamp.

The trap to avoid early is treating flags as free. Every flag you add is a branch in your code and a line item someone must eventually remove. A flag that outlives its purpose becomes dead complexity, and a codebase full of stale flags is genuinely worse than one with none. Naming and cleanup discipline, which later chapters cover, are what separate teams that love flags from teams that drown in them.

Key takeaways

• A feature flag is a runtime controlled conditional - if (flags.isEnabled(...)) - that ships in the build but is decided later.
• “Feature flag” and “feature toggle” mean the same thing.
• The core value is decoupling deploy from release, which unlocks safe incomplete merges, instant rollback, calm release timing, and testing in production.
• Good systems evaluate flags locally from an in memory rule set, so evaluation is microsecond fast and adds no per request network cost.
• Every flag has a lifecycle cost. Add them deliberately and plan to remove them.

Next

Now that the fundamentals are in place, the next chapter breaks flags into their distinct categories - release, ops, experiment, and permission toggles - because the right lifecycle and owner depend entirely on which kind you are building. Continue to types of feature flags.