The Case Against Feature Flags in Trading Systems

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.

Trading systems are not that context. In a latency-sensitive execution path, 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 order entry, risk evaluation, or market data processing. If a feature is ready, it ships. If it is not ready, it lives on a branch. We use compile-time configuration for hardware-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 software, we believe it leads to better outcomes.