Feature flags.
Feature flags decouple deployment from release: code ships disabled and is enabled by configuration, for specific users, percentages or environments, and can be turned off without a deployment.
Where Feature flags fits on a long engagement.
Separating deployment from release changes how a team works. Incomplete work can be merged behind a flag rather than living on a long branch, which removes the painful integration that long-lived branches guarantee, and a problematic feature is disabled in seconds rather than rolled back.
Flag debt is the cost nobody plans for. Flags accumulate, each one doubling the notional paths through the code, and a codebase with two hundred stale flags has a combinatorial set of states nobody has tested and nobody dares remove.
What an assigned team does with Feature flags.
Removal has to be part of the process rather than an intention. A flag needs an owner and an expected removal date at creation, or it stays forever — and the cleanup is never anybody's priority.
Holding that discipline across years is exactly what a standing assignment does, and what it covers is set out in how the monthly fee is built.
What we use Feature flags for.
- Merging incomplete work safely Trunk-based development without long branches and painful integration.
- Disabling a feature without deploying Seconds to turn something off rather than a rollback.
- Flags removed on schedule An owner and a date at creation, because cleanup is never prioritised otherwise.
How Feature flags capacity is assigned.
Delivery practice is assigned inside development capacity, with flag removal treated as part of the definition of done.
Tell us what your roadmap needs Feature flags for.
A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.
Loading the contact form… You can also email hello@azendo.co.
We reply within one working day. No obligation, and no newsletter.