Ask Your Dev Team how they use feature flags

Feature flags let a team deploy code while controlling whether a capability is available. Used carefully, they separate deployment from release and let you expose a change to a smaller group before everyone receives it.

They are switches inside the software, not a substitute for testing or a permanent safety net.

One change, several release choices

Imagine your team has built a new account dashboard. Without a feature flag, putting its code in production may expose it to every customer at once.

With a flag, the team might first enable the dashboard for employees, then a group of willing customers, and finally the full audience. If monitoring reveals a problem, they may be able to turn off the new experience without deploying another build.

That flexibility can reduce the number of customers affected while the team validates real behavior. It can also help coordinate a release that depends on marketing, training, another system, or a specific date. AWS’s current AppConfig documentation describes multi-variant feature flags for user segmentation and traffic splitting. The idea is broader than any one cloud service: release the capability to a deliberate audience instead of treating every deployment as an all-customer event.

Ask who gets the feature and why

A flag can target more than “on” or “off.” Depending on the implementation, availability might differ by customer account, permission, location, or a selected percentage of traffic.

That power needs a release plan. Who enters the first group? What evidence allows the next group in? Which customer or operational metric would pause the rollout? How will support know which experience a customer sees?

The answers should match the risk. An internal report may need a simple switch. A new payment flow needs careful audience selection, monitoring, and a defined recovery path.

A switch can fail too

Feature flags add decisions to the running application. Poorly managed flags can create confusing combinations, make testing harder, and leave old paths in the code long after a release is complete.

Every flag should have:

• A named owner who understands its purpose
• A default state and expected behavior if the flag service has a problem
• A release or operational reason for existing
• Monitoring appropriate to the change it controls
• A removal condition or review date

A short-lived release flag should usually disappear after the rollout is stable. A long-lived operational control, such as temporarily disabling an expensive feature during an incident, deserves ongoing documentation and testing.

Know what turning it off actually does

Disabling a visible feature may not undo actions already taken. If customers created data through the new dashboard, the old experience still needs to handle that data safely. If the release triggered payments or emails, the flag cannot pull them back.

Connect the flag plan to the rollback questions in issue 39. A flag can be one recovery mechanism, but the team must define its boundary.

Questions for the release conversation

“Why does this change need a feature flag?” Look for a specific release, testing, or operational purpose.

“Who can change it, and is that change recorded?” Production controls need clear access and accountability.

“What tells us to expand, pause, or reverse the rollout?” Decide using customer and system evidence.

“What happens to users and data when the flag is turned off?” The safe behavior should be understood before release.

“When will we remove or formally retain this flag?” Temporary controls shouldn’t become invisible permanent complexity.

I like feature flags when they buy a team a deliberate release decision. The switch is useful only when ownership, evidence, and cleanup come with it, at Cuttlesoft or anywhere else.

Go build something and expect better from your developer.