Feature Toggles for Web Apps: Letting New Work Run Beside the Main Roadmap

Web apps rarely get the luxury of building a new capability in isolation. The main branch keeps moving, other teams keep releasing, and a half-finished feature that lands in the shared codebase is a risk to everyone else. Feature toggles, also called feature flags, are a common way to separate two decisions that used to be tied together: when code is deployed and when users see the behavior it adds. This article covers how to use them without creating a second maintenance burden.

Four kinds of toggle, four different lifetimes

Pete Hodgson’s article on feature toggles, published on Martin Fowler’s site, sorts toggles into categories by how long they live and how dynamic they are. Release toggles hide unfinished work and are meant to be short-lived. Experiment toggles split traffic between variants and live as long as the experiment runs. Ops toggles let operators switch off a risky behavior in production. Permissioning toggles expose features to particular groups of users and may stay for years.

The categories matter because they call for different handling. A release toggle that outlives its purpose becomes clutter. A permissioning toggle removed too early takes a capability away from the group that depends on it. Naming each toggle with its category and an owner is a small habit that prevents most of the confusion later.

Using release toggles for work beside the core

For a new capability that has to grow next to an existing system, the release toggle is the relevant kind. The new code is merged in small steps and deployed with the toggle off, so the shared codebase stays releasable and the existing roadmap is not blocked. A product owner or tester switches the toggle on in a staging or limited environment to look at the behavior against the agreed acceptance criteria. Only when those criteria are met does the toggle open for real users.

Three rules keep this arrangement safe.

Keep the number of places that check the toggle small. One decision point near the entry of the feature is easier to reason about than the same condition scattered through many files.
Test both states. The off state is what current users see, so it needs the same protection as any other production behavior. The on state needs the new acceptance scenarios.
Give every release toggle a removal date and a person responsible for removing it.

Handing the decision to the product owner

A toggle is also a decision interface. Turning it on is a product decision, not an engineering one, and it works best when the person who owns the intent can see what is behind the switch. A short note beside each toggle, stating what the feature does, which criteria it must meet and who accepts it, turns a technical mechanism into a visible release decision.

Product teams that work with an outside partner on a bounded piece of new functionality can use the same device to keep the partner’s work apart from the team’s own releases. Product owners weighing feature development services from JetRuby, which build alongside an existing core with criteria agreed first and the result accepted against them, can read how that offer is framed on its page. The toggle is the code-level counterpart of that boundary: the new work is present in the codebase but does not reach users until someone with the authority to accept it says so.

What to watch in review

Toggles change what a reviewer should look for. The usual questions about correctness still apply, and three more join them. Does the off path behave exactly as before? Is the toggle read in one place, or is the condition leaking into unrelated modules? Is there a visible plan for deleting it? A toggle that arrives without answers to these questions is a future cleanup task disguised as a finished feature.

Interactions deserve attention too. Every toggle doubles the number of paths through the code it guards, and several toggles active at once can combine in ways nobody has tried. Keeping release toggles independent of one another, and avoiding toggles that depend on other toggles, reduces the number of combinations a team has to reason about.

Cleaning up

Toggles carry a cost that accumulates quietly. Hodgson’s article advises treating them as inventory that has a carrying cost and keeping that inventory small, which in practice means removing a toggle as soon as it has done its job.

A removal routine is simple. When the feature is accepted and fully released, delete the toggle and the old code path in one change, run the usual tests, and confirm that nothing else referenced the flag. Scheduling this step at the moment of release is easier than rediscovering a forgotten flag months later.

A short checklist

Before merging the first change behind a release toggle, it helps to confirm the following.

The toggle has a name that describes the feature, not the team.
Its default is off in every environment where users are present.
The acceptance criteria for the feature are written down and linked from the toggle’s note.
One person is named as the one who turns it on.
A removal task exists in the backlog.

None of this is elaborate. The value lies in treating the toggle as part of the product’s release process rather than as a private trick of the engineers who wrote it. With that treatment, new work can grow beside the main roadmap without either one blocking the other.