Open-source or vendor?

If you want fast adoption with strong audit and targeting, vendors like LaunchDarkly or Split work well. If you want Git-first and self-hosted, Unleash or Flipt are solid. Use OpenFeature to keep your options open.

How many flags are too many?

The wrong number is the number you can’t clean up. Budget time to delete. Tag every flag with owner and expiry, and enforce removal in CI. A healthy org can carry dozens of active flags if they’re visible and expiring.

Client-side or server-side evaluation?

Server-side by default for risky features. Client-side for UX experiments with strict caching and safe defaults. Mobile needs offline bundles and long TTLs. Never send PII in contexts; use a hashed key.

Can flags replace staged rollouts?

No. Use flags to gate behavior and feature exposure. Use canary/blue-green for binary changes. Together they’re safer than either alone.

How do we connect flags to business outcomes?

Tag events, traces, and metrics with `feature` and `variation`. Maintain a control cohort. Your experimentation platform (or a simple warehouse query) can compute deltas. Track CFR and MTTR per flip in your release dashboard.

Release-engineering · Oct 4, 2025 · 10 minute read

Feature Flags Without Regret: The Design That Halved Change Failures and Shrunk MTTR

Stop playing roulette with flag flips. Here’s the design, guardrails, and checklists that make experimentation safe—and measurable—for real engineering orgs.

Matt K.

Partner, Release Engineering at GitPlumbers

20 years in the trenches building and rescuing release systems at retailers, fintechs, and unicorns. Ex-Atlassian, ex-Shopify. I break glass only when the runbook says to.

Flags are not if-statements; they’re safety equipment. Treat them like seatbelts with sensors, not duct tape on the dashboard.

Back to all posts

Feature Flags Without Regret: The Design That Halved Change Failures and Shrunk MTTR

Key takeaways

Implementation checklist