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 measure performance changes.
There can be reasons for doing that but it’s really important not to tie all these things together: not every development lifecycle change is an ab test hypothesis. Not every ab test hypothesis is a development lifecycle change (often it is really about testing changes in data, and feature config is just one piece of data you might want to change). Similarly some other data changes than code changes need to roll out progressively to mitigate risk.
So all these things might be feature-flag shaped, but that doesn’t mean you can substitute different feature flag solutions in and solve the same problems.
This post is saying ‘it’s okay not to have an exposure control solution; you can have a config file’ - which is obviously true, if what you have is a config management problem, not an exposure control problem.
Strongly agree that Config & FeatureFlags are two different things. But as I've tried building tools in the space: man is it difficult to really nail down what the difference is.
For Quonfig I landed on:
- Data model wise they are identical. Flags and configs can both be targeted. They can both use segments. They can both do partial rollouts. They can both have the same range of values (bool/number/duration/json/json-w-schema/etc)
- Its fine to use Flags for your Experiments/AB Tests, but that's just the "allocation engine". The rest of experimentation is the exposure tracking and goal tracking. Those ought live in your product analytics stack, because they are really just events. But its helpful to have a single place (flags) for the experiment allocation because then you can re-use segments for things like hold out groups / and just general targeting.
- The only real difference is that Flags are intended to be ephemeral and configs are intended to be permanent. A good UI should show you how long a flag has been alive and help you clean it up (or convert it to a config) if it's been true for everyone for too long.
- The use cases are different enough that it's worth keeping them in two separate UI.
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.
Your second startup dedicated to feature flags? Aren't these just some booleans with optional support to toggle them at runtime? Maybe I've just not been in the right domain, but I would have thought that if someone's use of feature flags is so complicated that they need a whole company to support it then they've massively overengineered their code.
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.
This of course depends on the quantity and the depth of these feature flags. It’s ok to hard code few of them, maybe it’s not when it becomes a practice and you have tens of them. I think you would have a much easier life if there was a standardized, well documented, way to define them.
Hardcoded feature flags becomes a big issue if your release process is long and error prone. Original article also suggest to enhance incrementally. But you don't want the interval between increments to be too big.
Why wouldn't it be? The post does a good job explaining why not only it's not a problem, but also likely desirable in many (I'd wager the vast majority) of circumstances.
Simple, effective, cheap, easy to understand and manage. Not dependent on an external service, not dependent on a third-party.
To do safe deployments, you must have a way to run versions X and X+1 side by side serving an arbitrary proportion of your users while you inspect metrics.
That covers a lot of uses of feature flags without the bloat.
Unclear how the arguments against feature flags can be used to justify hardcoding them or using a JSON file to manage them. Feature flag decisions are at the end of the day, tradeoffs to solve a problem that may occur for another person at a different place/time. If you are a solo developer, hardcode, use bytes or mail your feature flags - it does not matter. If you are not, there is a lot to take care of beyond a single hardcoded json file.
Hardcoding feature flags prevents you from deploying the same build with different flag sets side by side and comparing results. Depending on the nature of the project, it might be irrelevant or it might be a deal breaker. Especially in cloud environments, it's usually the latter. And everything is in the cloud nowadays.
I've never found feature flag systems complex and you can build one yourself in a few functions. The services I have used in the past were extremely simple to integrate so I don't understand the issue either way honestly.
Do all modern compilers do tree-shaking at this point? Unless you use compiler-based flags, If you hard code them into your code, the dead code paths may still be in the shipped binary. Depending on what you are doing, the security issues mentioned in the article are still present, or you may prematurely reveal an upcoming feature.
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 measure performance changes.
There can be reasons for doing that but it’s really important not to tie all these things together: not every development lifecycle change is an ab test hypothesis. Not every ab test hypothesis is a development lifecycle change (often it is really about testing changes in data, and feature config is just one piece of data you might want to change). Similarly some other data changes than code changes need to roll out progressively to mitigate risk.
So all these things might be feature-flag shaped, but that doesn’t mean you can substitute different feature flag solutions in and solve the same problems.
This post is saying ‘it’s okay not to have an exposure control solution; you can have a config file’ - which is obviously true, if what you have is a config management problem, not an exposure control problem.
Strongly agree that Config & FeatureFlags are two different things. But as I've tried building tools in the space: man is it difficult to really nail down what the difference is.
For Quonfig I landed on:
- Data model wise they are identical. Flags and configs can both be targeted. They can both use segments. They can both do partial rollouts. They can both have the same range of values (bool/number/duration/json/json-w-schema/etc)
- Its fine to use Flags for your Experiments/AB Tests, but that's just the "allocation engine". The rest of experimentation is the exposure tracking and goal tracking. Those ought live in your product analytics stack, because they are really just events. But its helpful to have a single place (flags) for the experiment allocation because then you can re-use segments for things like hold out groups / and just general targeting.
- The only real difference is that Flags are intended to be ephemeral and configs are intended to be permanent. A good UI should show you how long a flag has been alive and help you clean it up (or convert it to a config) if it's been true for everyone for too long.
- The use cases are different enough that it's worth keeping them in two separate UI.
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
Your second startup dedicated to feature flags? Aren't these just some booleans with optional support to toggle them at runtime? Maybe I've just not been in the right domain, but I would have thought that if someone's use of feature flags is so complicated that they need a whole company to support it then they've massively overengineered their code.
Launchdarkly and Statsig are both well-established companies that basically do feature flags+add-ons.
You can do much more with feature flags like ab testing/experiments, integrations with analytics.
There can be whole UIs and tooling and infrastructure to manage around them and that’s what the sass offer
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.
You need to be actively deleting them after the feature has gone live
Create story to add feature flag controlling access to the feature.
Immediately create story to remove said feature flag controlling access to the feature and review it during backlog refinements.
This of course depends on the quantity and the depth of these feature flags. It’s ok to hard code few of them, maybe it’s not when it becomes a practice and you have tens of them. I think you would have a much easier life if there was a standardized, well documented, way to define them.
Brother
Yep, right up there with Triplebyte back in the day and the drumbeat about "it's so hard to bill customers" and "JWT sucks"> Hardcoded feature flags ... start with a simple JSON file
Any configuration read out of a JSON file is not hardcoded. Hardcoded means you need to recompile to change it.
(And yes, hardcoded, as in flags set with #define or equivalent, are totally fine depending on what you're doing.)
Depends on how you deploy. If changing it in prod requires a PR merge and a release approval, I’d consider that pretty hardcoded.
That's a bit too rigid of a definition. Just means it requires a code update to change it, that's hardcoded.
Hardcoded feature flags becomes a big issue if your release process is long and error prone. Original article also suggest to enhance incrementally. But you don't want the interval between increments to be too big.
Why wouldn't it be? The post does a good job explaining why not only it's not a problem, but also likely desirable in many (I'd wager the vast majority) of circumstances.
Simple, effective, cheap, easy to understand and manage. Not dependent on an external service, not dependent on a third-party.
To do safe deployments, you must have a way to run versions X and X+1 side by side serving an arbitrary proportion of your users while you inspect metrics.
That covers a lot of uses of feature flags without the bloat.
Unclear how the arguments against feature flags can be used to justify hardcoding them or using a JSON file to manage them. Feature flag decisions are at the end of the day, tradeoffs to solve a problem that may occur for another person at a different place/time. If you are a solo developer, hardcode, use bytes or mail your feature flags - it does not matter. If you are not, there is a lot to take care of beyond a single hardcoded json file.
Hardcoding feature flags prevents you from deploying the same build with different flag sets side by side and comparing results. Depending on the nature of the project, it might be irrelevant or it might be a deal breaker. Especially in cloud environments, it's usually the latter. And everything is in the cloud nowadays.
I've never found feature flag systems complex and you can build one yourself in a few functions. The services I have used in the past were extremely simple to integrate so I don't understand the issue either way honestly.
Do all modern compilers do tree-shaking at this point? Unless you use compiler-based flags, If you hard code them into your code, the dead code paths may still be in the shipped binary. Depending on what you are doing, the security issues mentioned in the article are still present, or you may prematurely reveal an upcoming feature.
note that this is a "pre-november 2025 opus 4.5" post folks