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 this product 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.
Saying so is more useful than implying otherwise. If you are choosing tools and the requirement is progressive delivery, that is a different category of product and this page is not trying to sell you one.
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.
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.
14 days, a card at signup, then $9 or $39 a month.
