We keep having to redeploy just to turn features off

That’s usually a sign the feature flagging / config strategy is too tightly coupled to deployments.

A few common fixes:

1) Use runtime feature flags

Store flags outside the app build/deploy so you can flip them without redeploying:

• LaunchDarkly
• Unleash
• ConfigCat
• Firebase Remote Config
• homegrown DB/config service

Then code checks the flag at runtime:

if (featureFlags.newCheckoutEnabled) {
  showNewCheckout();
} else {
  showOldCheckout();
}

2) Use dynamic config

If you don’t need full feature-flag tooling, keep settings in:

• a database table
• Redis
• S3 / config file fetched on startup + periodically refreshed
• environment-backed config service

This lets you disable a feature by updating config, not code.

3) Separate release from activation

Deploy code “dark” behind a flag, then turn it on gradually:

• off by default
• enable for internal users
• enable for a percentage of traffic
• fully roll out
• quick kill switch if issues appear

4) Add a kill switch for risky features

For anything high-risk, make sure you can turn it off immediately without waiting for CI/CD.

5) Avoid environment variables for fast toggles

Env vars are fine for deployment-time config, but if you have to restart/redeploy to change them, they won’t solve this problem by themselves.

If you want, I can help you design a simple feature-flag setup for your stack (e.g. Node, Python, Java, React, etc.) that lets you turn features off instantly.