Feature flags for shipping change: rollouts, targeting, schedules and experiments

“If you do a big-bang release, the only thing you’re guaranteed is a big bang.”

That’s how Sergio Revilla Velasco, head of engineering at Mercadona Tech, describes the release model his team left behind. Mercadona Tech now releases to production more than 100 times a day.

Writing and deploying code keeps getting cheaper, especially with AI coding assistants in the loop. The risk now sits in deciding who sees a change and when. A feature flag moves that decision to after the deployment, where you can widen it or reverse it in seconds.

The examples below are grouped by mechanism: gradual rollouts, advanced targeting, scheduled changes and A/B tests.

You’ll find more financial services examples such as jurisdictional gating, sanctions response, DR exercises, and the ramp back after a regional failover in our article on operational feature flags for financial services.

Gradual rollouts

A gradual rollout exposes a change to a growing share of traffic, and stickiness decides which unit moves together: a user, a session, a store or a whole customer account. Teams use the same mechanism for very different goals.

Canary a rebuilt checkout

Wayfair‘s SRE team points out that even a small change to recommendations or checkout reaches millions of customers and puts millions in revenue at risk.

Release a rebuilt checkout to 1% of shoppers with stickiness on user ID in Unleash, so nobody flips between the old and new flow halfway through a cart. Then watch payment success and error rates for that group, and widen in steps: 5%, 20%, 50%, and finally everyone.

If something looks off, the old checkout is still serving most of your customers, and one change takes the early group back to it.

Store by store, hive by hive

Mercadona rolls each feature out to one of its dedicated fulfillment centers first, which it calls “hives”. From there it moves to a set of stores, then a region, and only then nationwide.

Retailers and hospital groups share this shape, because the unit of risk is a physical location with staff who need to know what changed. Set the location ID as the stickiness field and every till in a store switches at the same moment, which keeps training and support calls simple.

Rings, from employees to everyone

The AA shows new features to its own staff first and then to a small slice of customers, widening to everyone once the data supports it.

In Unleash, a reusable segment for employees makes the first ring a one-click choice on any flag. The second ring can be a percentage of customers in a single market, picked so a problem stays small and easy to spot.

Rewrite a core service

Samsung Ads put one of its first flags around a new Golang-based bidding system, a latency-sensitive service where performance and stability mattered most. The team tested Unleash’s open source version against real production traffic before committing.

Route a small share of requests to the new service and compare its latency and error rates with the old one through impact metrics. Then keep widening while the numbers hold.

Replace a legacy system

Lloyds Banking Group used to bundle changes into a monolithic release every three to four weeks, and a defect in one feature rolled back unrelated work from other teams. More than 600 customer journeys now deploy independently.

The bank reports a 35% improvement in release times, and flags have supported moving half of its applications to the cloud while legacy systems retire gradually.

The AA took the same approach to a legacy CMS migration, testing the new system in production without any content problems reaching customers.

Switch payment processors

A marketplace moving to a new payment processor can route 2% of transactions to it and compare authorization rates by card type and country before sending more. A drop in approvals for one card network shows up while it affects a few hundred orders, and the old processor is still there to take them back.

Protect the call center

Every time a utility redesigns its bill, some share of customers call to ask what changed. Send the new format to 5% of accounts per billing cycle and the support team sees a bump it can staff for, along with the questions that belong in the FAQ before everyone gets the new bill.

New models, from fraud scoring to support assistants

Model changes are hard to judge in a test environment, because their behavior depends on real traffic. Lloyds uses flags to try AI-driven features in controlled environments and to manage AI model rollouts before scaling them.

A new fraud model can score 5% of transactions in the background while the old model still makes the decisions. A telecom support assistant can start with 2% of chats. For the runtime side of AI, such as switching models and prompts without a deploy, see how we control our own AI agent at runtime.

Betas and early access

Each kind of beta program maps to a different stickiness or targeting choice.

For B2B software, the account is the unit. Mintlify rolls features out with stickiness on organization ID, so everyone in a customer’s workspace sees the same thing. Consumer apps tend to use user ID, which keeps a beta tester in the beta every time they sign in.

Opt-in betas let users decide for themselves. Unleash leaves the opt-in screen to your app: add a “try the new version” toggle in settings, store the choice in the user’s profile or a cookie depending on how long it should last, and pass it to Unleash as a custom context field for that feature. A constraint on that field does the rest, and users can leave the beta whenever they like.

Rollouts that run themselves

Release templates turn a rollout plan into milestones that Unleash moves through on its own, such as 5% for a day, 25% for two days, 50% for another day and then everyone. A safeguard watches an impact metric during each step and pauses the progression if, for example, the error rate crosses a threshold.

Mintlify made gradual rollouts the default for new features, moving each one from 0% to 100% over several hours.

Advanced targeting

Targeting decides who sees a change based on what you know at request time. Constraints check fields in the Unleash context, such as plan or app version, and segments let you define a group once and reuse it across flags.

Plan tiers and entitlements

A SaaS product with several plans can gate premium features on a plan field in the context. Sales can switch a feature on for a prospect during a trial by adding the account to a segment, and a scheduled change request can take it away again on the day the trial ends.

App versions and devices

Mobile features often depend on code that only exists in newer builds. Semver operators on an app version field let you enable a feature for version 5.3 and above, or exclude one Android build with a known bug. Your app passes its version in the context through the Android, iOS, Flutter or React Native SDK.

One customer at a time

An enterprise customer hits a bug and can’t wait for the next release train. Ship the fix behind a flag constrained to that customer’s ID, confirm it with them, then roll it out to everyone else at your normal pace. The same pattern gives a design partner early access to a feature months before general availability.

Keep high-value accounts out of risky rollouts

Some customers you’d rather not surprise, such as your largest enterprise accounts or a public sector client with strict change windows. Put them in a segment and add a negated constraint to every early rollout stage, so they join only at the final milestone.

Targeting without moving personal data

Targeting on plan or account type means passing that data to the flag system. Backend SDKs evaluate flags inside your own application, so the context stays in your infrastructure.

At The AA, keeping evaluation server-side for anything involving personal data is what won over the data and privacy team.

Scheduled changes

Some releases have a date attached before anyone writes a line of code. Unleash offers two ways to hit it: date constraints on the current time, and scheduled change requests that get reviewed ahead of time and applied at the moment you set.

Launch at a fixed moment

A Black Friday sale that opens at midnight and a product launch under press embargo both go live at a time unrelated to your deploy schedule.

Deploy the code days earlier, switched off. A DATE_AFTER constraint turns it on at the exact minute, and a separate strategy per market handles time zones, so Sydney opens hours before London.

Promotions that end themselves

A promotion that outlives its end date costs money, usually over a weekend when nobody is watching. Pair a DATE_AFTER and a DATE_BEFORE constraint on the same strategy and the promotion runs exactly between those two moments.

Tax and regulatory effective dates

Governments change VAT rates and disclosure rules on fixed dates, often announced months ahead. Put the new rule behind a flag and have finance or legal approve a scheduled change request weeks before it applies. The audit log then shows exactly when the change took effect and who signed off.

Maintenance windows

When a payment provider announces two hours of maintenance on Sunday at 2am, schedule one change that hides that payment option as the window opens and another that brings it back when it closes.

A/B/n tests

Strategy variants split traffic into two or more groups with consistent assignment, and impression data sends each assignment to the analytics tools you already run. Unleash handles the split and the rollout, and your product analytics or data warehouse does the analysis.

The AA reports a 20% lift in conversion on key customer journeys from data-backed rollouts and experimentation.

Mintlify gave a coding agent the job of testing whether an editor panel should sit on the left or the right. The agent built both versions, created a 50/50 rollout sticky on organization ID and sent each assignment to PostHog, and a person made the call to go to production.

Yousician uses Unleash to keep test assignment consistent across the different places its users meet the product.

After the rollout

A release flag has done its job once the feature reaches 100%, and every one left in the code is a branch someone has to reason about later. Unleash tracks each flag through lifecycle stages and marks it as potentially stale once it passes its expected lifetime.

Dunelm used its migration to Unleash to cut active flags from about 125 to 80, and found that flags removed soon after launch are much easier to clean up than year-old ones. Mintlify archives aggressively and treats a flag count that only ever climbs as a warning sign.

Unleash is the FeatureOps platform that companies including Mercadona, Lloyds Banking Group, The AA and Samsung use to control how and when changes reach their customers.

If you’re planning any of the rollouts above, we’d like to help.