“Could we just put it behind a feature flag?” is often offered as a sensible compromise when a team has not quite agreed about a feature.
One person thinks it fills a gap, creates a useful point of difference, or opens up a new way for customers to use the product. Another is not convinced. They may feel that the feature is unnecessary, that customers will find it strange, or that it is taking the product in the wrong direction.
A flag seems to offer a way through that disagreement. Build it, expose it to a small group, and see what happens. If customers do not use it, or it causes problems, turn it off.
What a flag can help with
There are good reasons to do this. A feature flag can be useful when the uncertainty is really about exposure. Perhaps the feature is ready to deploy but support, training or another dependency is not ready for a full launch. Perhaps it needs to be tested with a particular group of customers first. Perhaps there is a genuine need for an operational switch that stops a risky path while the team investigates a problem.
It can also help resolve a product argument with evidence. A partner who knows the market well and says that a feature “feels weird” is not necessarily right or wrong. It may point to a genuine customer expectation that needs to be understood. It may reveal an adoption problem that needs solving. Or it may be exactly where the opportunity lies.
A controlled release can help distinguish between those possibilities, provided the team is clear about what it is trying to learn.
What turning it off does not undo
The trouble starts when “we can turn it off later” becomes shorthand for “we can safely roll it back later.” A feature flag can control who sees a button, who enters a workflow, or which path the application follows. It does not necessarily return the system to the state it was in before the feature existed.
That distinction matters as soon as the feature affects more than an isolated piece of interface.
Imagine a new option that changes how customers buy, use or configure a service. It may require new records, different permissions, additional states in an existing workflow, changes to billing, or data passed into another system. The application may need a schema migration to support it properly.
Once real customers have used that feature, turning the flag off may prevent new customers from using it. It does not remove the records already created, reverse the migration, retract events sent to another system, or settle the question of what should happen to customers who are already on the new path.
The product has changed, even if the interface is now hidden.
The cost of carrying both paths
In some cases, the flag also makes the implementation more complicated than a clean change would have been. If a team decided to replace one workflow with another, it might be able to migrate the relevant data, update the schema, and move forward with one coherent model. Adding a flag can mean supporting the old workflow and the new one at the same time.
That affects more than the code. Support needs to know which version a customer is using. Reporting needs to make sense of both. Developers making the next change need to understand which assumptions still apply, and where backwards compatibility is genuinely required. Testing becomes a question of whether every combination of state and flag still behaves sensibly.
Sometimes that additional complexity is worth carrying. A staged migration may be the safest way to change an important system, particularly where there is real operational risk or a large existing customer base.
Sometimes it is simply an expensive way of postponing a decision.
Start with the uncertainty
Before adding a flag, I think it is worth being specific about the uncertainty it is meant to manage. Is the question whether customers will value the feature? Whether the organisation is ready to launch it? Whether the implementation is safe under real usage? Or whether the team has not agreed what the product should do?
Those questions can lead to different answers.
If the point is to learn whether customers want something, the team needs a clear hypothesis, a sensible group to test it with, and some idea of what result would cause the feature to be kept, changed or removed. If the point is operational safety, there needs to be a known safe state when the switch is turned off. If the point is a staged migration, the team needs to understand how long both versions of the system will exist, what data each one produces, and how it will eventually remove the old path.
A flag can be a useful tool for managing uncertainty. It does not remove the product, technical or opportunity cost of building the wrong thing. Sometimes it gives a team the space to make a better decision with real evidence. Sometimes it conceals the fact that the application is now carrying two versions of reality, neither of which anyone has properly committed to.
The useful question is not only whether a feature can be hidden later. It is what remains true about the system, its data and its customers after it has been used.
If you are working through a decision like this and want to get clear on the consequences before committing to a path, tell me what’s going on.