← Glossary

Feature flag, and what it changes about shipping

A feature flag is a switch in the code that turns a piece of behaviour on for some users and off for others, without deploying anything new.

The point is to separate two events that used to be one. Code reaching production and a feature reaching a customer become different decisions, taken at different times, by different people. Almost everything written about flags follows from that separation.

What is a feature flag used for?

Four jobs, and they are different enough that teams often run different kinds of flag for each.

Releasing gradually. Turn the thing on for a few accounts, watch, then widen. If it goes badly the switch goes back without a deployment, which is the part operations teams care about.

Hiding unfinished work. Merge code that is not ready, behind a flag that is off, so the branch does not live for three weeks and turn into a merge problem.

Giving access to specific accounts. Early access for the customers who asked, or a paid tier with things the free tier does not have.

Testing two versions against each other. The same switch, pointed at a measurement rather than at a rollout.

What does a feature flag cost?

Complexity that compounds, and the bill arrives later than the benefit.

Every live flag doubles the number of states the product can be in. Two flags make four, ten make a thousand, and no test suite covers them all. Code paths behind an off switch rot quietly, because nobody reads them and nothing fails.

The discipline that keeps this manageable is removing a flag as soon as it has done its job, and that is the step teams skip, which is how a codebase ends up with switches nobody dares to touch.

The second cost is that support gets harder. When two customers see different behaviour on the same version, the first question on every ticket becomes which of them is looking at what.

Does VoteFirst have feature flags?

No. There is no flag system in it and nothing in the product turns behaviour on for one account and off for another on that basis.

What exists is plan based access, which is a different thing wearing a similar coat. The plan an account is on decides what it can reach, and that is billing rather than a rollout mechanism. There is no switch anywhere for handing one customer an unfinished feature early.

If you are choosing tools and the requirement is progressive delivery, that is a different category of product.

How do flags and a public roadmap fit together?

Badly, unless you decide in advance what public means.

A flag makes shipped ambiguous. A feature can be in production, on for eleven accounts, and untouched by everybody else. If your roadmap says shipped at that moment, most of your customers will go looking for something they cannot see, and the resulting tickets are entirely your own fault.

The workable convention is that the roadmap column tracks availability rather than deployment. It moves when the customer reading the roadmap could actually use the thing. Everything before that is in progress, however live the code is. How the roadmap columns work here is written out in full.

The changelog has the same problem and an easier answer, which is to write the entry when the flag is fully on. A changelog entry that announces something a reader cannot find is worse than no entry at all. What belongs in a changelog and what does not is written up separately.

The roadmap embedded in an ordinary web page, drawing the board's four columns as a grid of cards with their vote counts
The roadmap running inside an ordinary web page.

Who should get the early access flag?

The people who asked, which is a list you should already have.

The obvious answer is the biggest accounts and it is usually the wrong one. The people who filed the request and voted for it are self selected for caring about that specific thing, which is exactly the group whose feedback on a half finished version is worth reading.

A board makes that list a query rather than a memory, because every request carries the voters behind it.

The better version of the question is which of the people who asked are paying you, and that is what the weighting is for. The formula and the code behind it are published. Every feedback tool's real price, laid out by the unit it actually bills on, is where to check which board can hold that list in the first place.

14 days, a card at signup, then $9 or $39 a month.

The insights rail beside the voter list, counting total, new and active voters, how many carry revenue, where they arrived from, and the requests with the most revenue behind them
The rail counting voters, revenue, and which requests carry money.

Related reading

What are release notes Release management, and where the changelog fits Changelog vs release notes, and which one you owe a customer Feature request, and what happens to one after it is typed Feature prioritization, and which inputs you measured Bug vs feature request, and the one question that decides Feature factory, and the metric that quietly creates one Feature creep, and the board that quietly causes it