Feature Flags vs Deploy: When to Use Each One

The problem

Some teams treat feature flags like a universal solution.

Some teams avoid flags and try to solve everything with deploys alone.

Both extremes make operations worse.

Because deploys and flags move different levers.

When that gets blurry, ugly symptoms show up:

• code is deployed, but the feature is still “mysteriously” off
• technical rollback and functional rollback get mixed together
• old flags get forgotten
• the product flow turns into a tree of if statements

Mental model

Separated cleanly:

• deploy decides which version of the code is running
• feature flag decides whether a capability is active, for whom, and when

In other words:

deploy moves the technical base

a flag controls functional exposure

Those two things can move together, but they are not the same tool.

Breaking the problem down

When deploy alone is enough

If the change is simple and the team is fine with a direct release, a deploy may be enough on its own.

Examples:

• internal refactor
• an adjustment with no new exposed behavior
• small fixes with low functional risk

Here a flag may only add extra complexity.

When a flag helps a lot

A flag makes a lot of sense when you want to:

• enable a feature gradually
• test with a small group
• turn it off quickly without a new deploy
• separate technical delivery from the business launch window

That is especially useful when the feature:

• is risky
• affects revenue
• depends on coordinated activation
• needs to be tested with a partial audience

A flag also does not replace deployment strategy

This is a classic mistake.

Even with a flag, the new code already reached production.

If that code introduces:

• CPU cost
• a startup bug
• a migration that breaks
• a compatibility problem

the flag alone will not save you.

It helps control functional exposure.

It does not erase every technical risk in that version.

Flags have a maintenance cost

Each flag adds:

• another conditional path
• another possible state
• a bigger test matrix
• cleanup work later

An old forgotten flag becomes hidden legacy.

That is why a good flag usually has:

• a clear goal
• an owner
• a removal criterion
• a cleanup deadline

Simple example

Imagine a new checkout flow.

The team wants to ship the code before Friday’s campaign.

It makes sense to do this:

1. deploy the new code
2. keep the feature off behind a flag
3. enable it internally for controlled testing
4. roll it out to 5%, 20%, 100%
5. use a quick kill switch if the error rate goes up

That is different from using a flag to hide code forever with no plan.

In the first case, the flag helps the rollout.

In the second, it becomes a storage room for ambiguity.

Common mistakes

• Treating a flag like a full alternative to deploy.
• Forgetting to remove the flag after stabilization.
• Creating a flag for every irrelevant detail.
• Using a flag as an excuse not to think about release strategy.
• Mixing product behavior with technical configuration without clarity.

How a senior thinks

People with more experience usually ask:

“Do I need to control feature exposure, code release, or both?”

That question organizes the decision very well.

Because it avoids putting a deploy problem inside a flag, or putting a functional rollout problem inside a deploy.

What the interviewer wants to see

In an interview, the evaluator wants to see whether you can distinguish delivery tools.

You move up a level when you:

• separate deploy from functional exposure
• mention gradual rollout and kill switch
• talk about the cost of keeping flags around
• recognize that a flag does not remove all technical risk

A strong answer usually sounds like this:

“A deploy takes the code to the environment. A flag controls whether that capability is active. I would use a flag when I need gradual rollout, experimentation, or fast shutdown, but I would be careful not to accumulate dead paths and unnecessary complexity.”

A good flag buys control. Too many flags buy confusion in installments.