The Case Against Feature Flags in Infrastructure Tooling

Feature flags are a beloved pattern in web and SaaS development. They let you decouple deployment from release, run A/B tests, and gradually roll out changes. In that context, they make perfect sense.

Infrastructure tooling is not that context. In a latency-sensitive service mesh proxy, every conditional branch is a potential cache miss, every configuration lookup is a potential point of indeterminacy, and every "dark" code path is a potential source of bugs that your test suite never exercises because the flag was off.

At Cox, we made a deliberate decision early on: no feature flags in any code path that touches request routing, TLS termination, or health checking. If a feature is ready, it ships. If it is not ready, it lives on a branch. We use compile-time configuration for platform-specific optimizations and build separate binaries for each target, which means dead code is truly dead — the compiler eliminates it entirely.

This approach forces discipline. You cannot hide behind a flag and ship something half-baked. Every release must be production-ready for every client, which raises the bar on testing and code review. It also makes debugging radically simpler: when something goes wrong, there is exactly one code path to investigate, not a combinatorial explosion of flag states.

We understand this is a contrarian position, and we do not claim it is right for every organization. But for small, focused teams building performance-critical infrastructure tools, we believe it leads to better outcomes.