It's OK to hardcode feature flags
It's OK to hardcode feature flags (2025)
Feature flag management software is often overkill. While it can be powerful, it adds complexity, risk, and infrastructure burden. Hardcoded flags, using a simple JSON file read at startup, are simpler, more reliable, and safer. They avoid non-deterministic behavior and long-lived flags that ossify codebases. For most teams, this approach is sufficient. Only when you truly need runtime changes at scale should you consider dedicated tools.
The blogspam marketing behind them is so strong, that admitting they’re unnecessary feels like confessing to technological impotence.
- avlcodemonkey
If you're working with C#, Microsoft added first class support for feature management in .Net with https://github.com/microsoft/featuremanagement-dotnet. It provides the logic for simple on/off, user targeting, percentage roll outs, and schedules. Using feature management along with flags hardcoded in `appSettings.json` makes perfect sense for a simpler application.
When your architecture grows and you start needing to synchronize configuration across multiple applications, or have non-technical users change flags, then you've probably outgrown hardcoding and need to consider building (or buying) a service. You probably don't want product owners trying to set an env var like `FeatureManagement__NewFeature__EnabledFor__0__Name`. Azure App Configuration is the go to if you're willing to use Azure - it provides a nice UI for editing flags instead of dealing with JSON. Or, I've been building https://featureflags.app/ as an alternative provider if you prefer to steer clear of Azure. Its kinda the middle ground between hard coding and a full on platform like LaunchDarkly.
- jameshart
In my experience these (configuration based feature flags and feature flag services) are actually two complimentary capabilities that solve two completely different problems but that happen to share the same name: feature flags.
The config approach is critical for using feature flags as a software development lifecycle tool. It is how you manage having a codebase which contains the unfinished code for new feature x, but can still be deployed and pass all tests without feature x being turned on.
In this model you need a mechanism which allows a developer who is working on feature x to enable it for local testing, and for your CI system to be able to interact with the flag system to test that the application works in both states - with x turned on and off.
This is ideal for trunk based development models; feature branches are an alternative approach that doesn’t really benefit from this (indeed it adds complexity to working in feature branches).
Meanwhile feature flag services are to solve the problem that different people using the same software need different features turned on. That can be as simple as internal testers or beta users, it can be holding features to roll out in fixed update windows per tenant, or it can be part of a risk management strategy where features are rolled out through progressive exposure.
It can also be tempting to mix up your feature flags system with an A/B testing system - you can use a feature flag service to expose a feature to a test cohort and […]
- stronglikedan
Unless you're Knight Capital, of course. https://www.youtube.com/watch?v=UuqSy1jPSUw
- jdwyah
I am on my second feature flag startup, but I also somewhat agree with this.
Every project should have flags, but many projects need just the basics and a service is overkill.
Rolling your own JSON still feels like something we ought avoid though. Yes to start out it’s 95% booleans. But then you want a rollout. And then you want some targeting rules. And then you want non booleans… maybe some json. Oo wouldn’t it be nice if the json could conform to a schema… and then eventually you are like damn I really want to change these without deploying. Or you want to read the same flag from multiple services.
I’ve tried to incorporate this lowest common denominator into https://quonfig.com Use it totally free & open source as SDK, and it’s just loading JSON that you can track in git. Agents love it, hot reloads, SDK in lots of languages. But vs rolling your own you’ve got a lot of headroom on the design. A bunch of targeting operators. Segments etc. And then if you do want to get a nice UI / delivery network for real time updates, then you can use the paid side of things.
Local use description: https://docs.quonfig.com/docs/how-tos/open-source-local
- maxidog
I’m currently reverse engineering a large enterprise app and the feature flag bloat is truly astounding. Imho excessive feature flag complexity is a symptom of management who are indecisive and mistrusted by the developers.