A Swedish SaaS team promises an enterprise customer an early version of a reporting feature. A developer adds a customer-ID check. Another customer needs the previous export format. A third gets a different approval screen. Six months later, support cannot reproduce a complaint without asking an engineer which combination of exceptions the customer has.
Feature flags can make controlled rollouts easier, provided the product treats targeting rules as managed configuration with owners and an end date. Without that lifecycle, a flag becomes another form of hidden product branching. The commercial cost appears in support, testing and the effort required to deliver the next feature.
Separate rollout, entitlement and permission
These three decisions often get mixed into one boolean. A rollout flag controls whether a release is enabled for a chosen audience. An entitlement expresses what the customer has purchased. A permission determines what a particular user may do. Combining them makes commercial changes unexpectedly alter security behaviour.
Write the decision path explicitly. A user may need the relevant entitlement, a permitted role and an enabled rollout before seeing the new interface. The backend must enforce the actual authorisation independently of whether the browser displays a button. A feature-management outage should not grant access that the user did not otherwise have.
For an initial project, choose one feature with a real rollout problem. Define which decisions the flag owns and which remain in your billing or access-control systems. That boundary is more important than choosing a fashionable feature-management vendor.
Make targeting understandable across requests
OpenFeature's evaluation-context documentation describes how contextual information can accompany a flag evaluation. This provides a useful abstraction for application code. Your team still needs to select stable identifiers and decide how customer, user and environment attributes are supplied.
For a B2B product, ask whether everyone in a customer organisation should receive the same version. Assigning each employee independently may produce contradictory workflows inside one account. A report created by a pilot user could become unreadable to a colleague who remains on the old version. Test those interactions before widening the rollout.
Avoid transmitting unnecessary personal information to the flag provider. A stable internal organisation reference and a small set of approved attributes may be sufficient. Document who can change those attributes and how a mistaken customer assignment is corrected. An email-domain shortcut is a poor substitute for a proper tenant relationship.
Choose failure behaviour before the first incident
Flags are runtime dependencies. Decide what should happen if the provider is unavailable, the local cache is old or an evaluation returns an unexpected value. For each important flag, document the intended default and the consequence of using it. One global default is unlikely to suit every feature.
The browser and server also need consistent behaviour. If the interface starts a new workflow while the API still evaluates the old path, the customer can become stuck between versions. Use an agreed release contract and preserve compatibility where a process crosses requests or runs for a long time.
A kill switch needs an operational definition. Turning off a new importer may prevent new jobs while allowing existing jobs to finish. Turning it off midway through a write could create a different failure. Rehearse the actual stop behaviour in a test environment, including the message users receive and the recovery path for work already started.
Measure exposure, not just clicks
A customer cannot respond to a feature they never received. Record enough information to distinguish assignment, actual exposure and a subsequent outcome. OpenFeature's tracking specification provides an interface for associating actions or application state with feature evaluations. Whether a chosen provider implements that capability must be verified.
Keep business interpretation separate from event collection. A rise in exports among pilot accounts does not by itself prove that the new screen caused it. The pilot group may be larger customers or unusually engaged users. Decide in advance whether the rollout is an operational safety check, a usability study or a properly designed experiment.
Support needs a practical view of exposure too. An authorised support agent should be able to see the relevant configuration revision and expected experience for one customer without gaining the power to change every rollout. Record changes with a reason so a complaint can be matched to the state that existed when it occurred.
Every temporary flag needs a retirement decision
Create a small register containing the owner, purpose, creation date, intended audience and review condition. A release flag may end when the new behaviour is accepted for everyone. A permanent entitlement belongs in a more durable model. A failed experiment may require removing both branches and its temporary data collection.
Retirement should include code, tests, configuration and documentation. Search for all evaluation points before deleting a flag. Check whether older mobile clients or background workers still depend on it. Preserve any audit information needed to explain past decisions without leaving the obsolete runtime switch active forever.
Ask the implementation partner to demonstrate a complete lifecycle: introduce a flag, expose a test tenant, widen it, handle an outage, disable it safely and remove it. Review how the test suite covers important combinations. Exhaustively testing every theoretical boolean combination is rarely practical; prioritise real workflows and incompatible states.
Our guides to single-customer recovery and software handover describe related obligations when one shared product serves many customers. A clear rollout model helps keep that shared product maintainable.
TuniCyberLabs develops SaaS platforms and business software. Show us a customer-specific feature that has become difficult to release. We can scope the targeting, compatibility and retirement work around that concrete problem.