How do you use feature flags to ship safely (what do you flag, how do you clean up)?

Here’s the quick version I share with teams when we’re ramping up flags: use them to make every deploy reversible, observable, and boring. Small toggles, measured ramps, instant rollback, and a calendar reminder to delete the darn things. 👇

What we flag

• Release toggles for incomplete code paths

• Ops/kill switches (e.g., force_readonly, disable_payments)

• Experiments (A/B/MVT)

• Risky integrations & pricing/entitlements

Rollout

• Cohorts: staff → dogfood → beta → % ramp (1 → 5 → 20 → 50 → 100)

• Progression gates: advance only if SLOs hold and error-budget hit < threshold

• Rollback: one-click off; dark path callable; documented plan

Guardrails

• Defaults off, config turns on

• Timeouts + fallbacks (circuit breaker around flagged code)

• Dependencies: depends_on: billing_v2 && auth_sso

• Fail-closed for security/billing; fail-open for UX

Observability

• Per-variant metrics: error rate, p95/p99, throughput, conversion

• Flag-scoped alerts: errors{flag=on} > 1% for 5m

• Dashboards comparing ON vs OFF; audit logs (who/why/when)

Governance

• Owner per flag, naming: <domain>.<feature>.<purpose>

• Config-as-code via PRs; link to ticket/rollback notes

• Expiry dates + bots/CI nags at T+14/30/60

Cleanup

• Release flags: remove after 7–14 stable days at 100%

• Experiments: merge winner, archive results

• Kill switches: keep; quarterly review

• Enforcement: nightly expired-flag report; CI fails on stale refs

Tooling

• Vendor: LaunchDarkly / Flagsmith / Split

• Standard: OpenFeature

• Homegrown: JSON + S3/Redis + cache + webhooks

Do/Don’t

• Do: keep flags thin, test both paths, document risk/rollback

• Don’t: nest flags, let them live forever, or bundle unrelated changes

“Safe to ship” metric

• Primary: Δ error rate + Δ p95 (ON vs OFF) within budget for ≥30 min

• Secondary: KPI guardrails hold.

How E-Sutra Uses Feature Flags to Ship Safely

(E-Sutra approach — https://e-sutra.com)

1) What We Flag

At E-Sutra, we use feature flags mainly for:

• Release toggles: safely deploy new features without exposing them immediately.

• Kill switches: instantly turn off risky features during incidents.

• Experiments: test changes with limited users before full rollout.

• Customer or region flags: enable features selectively.

Every flag has a clear purpose, owner, and planned removal date from day one.

2) Rollout Method

We always roll out gradually:

• Start with internal teams.

• Move to small user percentages.

• Expand to beta users or specific regions.

• Finally, enable for all users (GA).

A rollback plan is always ready so features can be disabled instantly without redeploying code.

3) Guardrails for Safety

To avoid failures:

• Safe default behavior if a flag system fails.

• Defined fail-open or fail-closed behavior based on risk.

• No complex flag dependencies.

• Timeouts and fallbacks built into the application.

These guardrails are reviewed during code reviews and audits at E-Sutra.

4) Observability & Monitoring

For every flagged feature, we track:

• Error rates and performance impact.

• User behavior and key business metrics.

• Real-time alerts if something goes wrong.

• Full audit logs of who changed a flag and when.

This ensures fast detection and fast recovery.

5) Governance & Control

E-Sutra follows strict governance:

• Each flag has an owner.

• Clear naming standards.

• Flag configuration is treated as code.

• Mandatory expiry dates to avoid long-living flags.

This helps us pass multiple quality and security audits consistently.

6) Cleanup Policy

Cleanup is mandatory:

• Flags are removed once the feature is stable and fully released.

• Old code paths are deleted, not left behind.

• Cleanup is tracked in the delivery process and enforced during reviews.

No stale flags, no technical debt.

Do’s and Don’ts (E-Sutra Standards)

Do:

• Plan rollback and cleanup before release.

• Roll out slowly and monitor closely.

• Keep flags simple and temporary.

Don’t:

• Leave flags forever.

• Use flags as permanent configuration.

• Skip monitoring or ownership.

Key Metric We Watch

The most important signal for safety is:
👉 Error rate and performance impact compared to normal behavior during rollout

If it crosses limits, we immediately disable the feature.

Tooling

We use a mix of industry-standard tools and custom internal systems, integrated with CI/CD and audits, to maintain high-quality, reliable releases at scale.

This approach helps E-Sutra (https://e-sutra.com) deliver safe, high-quality engineering, software, and digital solutions with confidence.