Custom Software Projects
Feature flags: Write the switch-off plan before release
Define a feature flag’s audience, failure default, data impact and switch-off decision. Plan a controlled rollout through a practical appointment example.
A team puts a new appointment-allocation method behind a flag to try it with a small customer group. When a problem appears, they disable the flag, but appointments created by the new flow cannot be read in the old screen. They have an on/off switch without a safe return path. This fictional service-booking example shows why feature flags require decisions about data and operations as well as visibility. A flag is not an automatic rollback solution for every risk.
Identify the single business decision the flag changes
In our example, the flag selects whether a new allocation method calculates available service slots. It does not decide access to a customer account or a staff member’s permissions. Hiding a button is not an authorisation check: the action needs its own server-side access controls. Attaching many unrelated changes to one flag makes it harder to identify which behaviour produced an outcome. Record both the affected workflow and the work that should remain unaffected in the scope card.
Choose the failure default through its business outcome
What happens when the flag provider cannot respond? Does the application return to a validated older method, or stop the action with a controlled explanation? Describe what the customer sees instead of recording only true or false. OpenFeature’s evaluation API specifies returning the supplied default value when evaluation fails. Whether that technical outcome is safe depends on the application’s choice. An empty appointment result and a provider failure should not silently become the same customer message.
Keep the audience and observation window stable
The first trial can be limited to explicitly selected pilot businesses. Staff from the same business should not encounter contradictory workflows; account-level targeting may be more appropriate than individual targeting. Do not copy sensitive customer information into logs or evaluation context merely to make selection convenient. Use the minimum information needed to identify the running path. During the observation window, review successful appointment creation and understandable failure reasons for both methods. Increased traffic alone does not demonstrate better quality.
Exercise both paths against the same data
Use a test record to find a slot, change an appointment and cancel it with the flag both enabled and disabled. Can a record created through the new method be read after returning to the old one? What happens if the decision changes during an operation? Disabling a flag does not automatically reverse a database change, an already sent notification or work opened in another system. If the new appointment fields are incompatible with the old screen, prepare compatibility or a separate recovery flow before rollout.
Connect the switch-off decision to a person and an observation
The rollout card needs an owner, a backup and a stopping condition. A confirmed duplicate appointment could be one condition in this fictional risk scenario, rather than a universal threshold. State where the decision-maker sees the evidence and which records must be checked after disabling the flag. If the feature’s involvement is uncertain, record investigation separately from intervention. Changes to the flag should be traceable to who made them, when and for what reason.
Remove a temporary flag when its job is finished
Do not close a pilot with only a note saying enabled. If the new method becomes permanent, create work to remove the old branch and redundant configuration. Otherwise, record why the trial ended. Ownerless flags can increase the possible states that require testing. Treat an expiry date as a review reminder rather than an instruction to delete automatically. Complete the handover by checking that remaining configuration and tests match the current code behaviour, so a small pilot does not leave lasting uncertainty.
Frequently asked questions
Is disabling a flag the same as rolling back a release?
No. A flag changes a particular code path; data, external actions and the deployed release need separate consideration.
Must a first pilot randomly split all users?
No. A clearly defined pilot group that preserves a coherent workflow may be easier to understand.
Can a flag replace an access check?
It can select visibility, but access permission must pass its own secure control.
When defining a pilot with BiKreatif, specify the failure default, switch-off decision and remaining data responsibilities alongside the feature being introduced.
Source
OpenFeature — Flag Evaluation API — https://openfeature.dev/specification/sections/flag-evaluation/