Feature flags
Also: feature toggles, release flags
What is Feature flags?
Feature flags are configuration switches that turn functionality on or off for specific users, tenants or percentages at runtime, so code can be deployed before it is released and rolled back without a redeploy.
What Feature flags means
A feature flag wraps a code path in a check: if the flag is on for this user or tenant, run the new behaviour, otherwise the old one. Flags are evaluated at runtime from a configuration service, so product and engineering can release to internal staff, then a beta cohort, then a percentage of traffic, then everyone, and reverse any step in seconds. Deployment (code reaching production) and release (users seeing it) become separate decisions.
Flags come in types with different lifetimes. Release flags are temporary and should be removed once fully rolled out. Permission or entitlement flags gate features by plan and are permanent. Operational flags act as kill switches for expensive or risky subsystems such as an AI model call. Experiment flags split traffic for controlled tests. Mixing these up, or never deleting old flags, creates a tangle of dead code paths.
For AI features, flags are how shadow mode and beta cohorts are implemented: the model runs for everyone but its output is shown only where the flag allows. Flags are not a replacement for testing, and they are not a configuration system for everything.
Who it really matters to
- CTO / Head of Engineering: flags decouple deploy from release, which makes trunk-based development and frequent releases safe.
- Product manager: staged rollouts and beta cohorts let you validate a feature with real users before committing to it.
- Support manager: a kill switch means a broken feature is turned off in seconds rather than after an emergency deploy.
- CFO: an operational flag on expensive AI features caps spend during incidents or unexpected usage spikes.
Why it exists
Feature flags exist because big-bang releases are risky and rollbacks are slow. Separating deployment from release lets teams ship small changes continuously, test with real users in production and retreat instantly when something is wrong. For AI features, whose behaviour cannot be fully predicted in staging, this is the only sane way to launch. The trade-off is flag debt: every flag is a branch in the code, and unremoved flags accumulate into paths nobody understands. Flags need owners and expiry dates.
Where it is applied
- A SaaS product rolling an AI summarisation feature out to a beta cohort of ten customers before general release.
- A FinTech app enabling a new credit decision model for a percentage of applications while comparing outcomes.
- A retail app switching a new checkout flow off instantly during a peak-season incident.
- A learning platform gating premium AI tutoring behind a plan entitlement flag.
- A logistics dispatch system testing a new assignment algorithm in one city before others.
Is Feature flags a skill?
Technique / practiceA release practice supported by tools such as LaunchDarkly, Unleash or a simple in-house service. Eazyware uses flags on every product it builds and treats them as the delivery mechanism for staged AI rollouts under the SaaS copilots and SaaS development services.
Eazyware service that covers it: SaaS / Cloud-native Application Development. Starting prices are on the pricing page.
Frequently asked questions
Do we need a feature flag platform or can we build our own?
A small team can start with a database table and a cached lookup. Move to a platform when you need percentage rollouts, per-tenant targeting, audit history and a UI that product managers can use without engineering help.
How do we avoid flag debt?
Give every release flag an owner and a removal date, review stale flags in each sprint, and distinguish temporary release flags from permanent entitlement and kill-switch flags. Remove the code path for the old behaviour once the rollout is complete.