Feature Flags: How to Roll Out a New App Feature

Imagine the last hour of a Friday sale. A customer pays, but the order never appears in the shop's warehouse queue. The team had released a new checkout to everyone that morning. A feature flag could have let the team try that checkout with a small group first. They might have spotted the missing orders while the older checkout still served most shoppers. Of course, somebody still had to test the old route, watch the order queue, and know who could turn the switch back.

What is a feature flag?

A feature flag is a rule to turn the feature on and off. This rule applies to all users, employees, a certain percentage of users, or to particular users by their name. For instance, a store can turn the new searching feature for its employees on Monday, five percent of users on Wednesday, and turn the feature on for everyone the next week.

The code for the new search feature can be deployed before deciding on turning the feature on. Deployment implies loading code into the production server. The release is making the change available for the users. The flag enables having these two steps at two separate moments. Staff can then try the live page before customers see it.

A switch cannot mend broken code. Before the first visitor sees the page, a colleague needs to try it and agree on a response if it fails. Later, that colleague can use the flag to stop more visitors from hitting the faulty page. The people who have already used it may still need help.

A clinic tries a new booking form

The receptionist at our example clinic often has to answer calls from patients who want a particular doctor. In the old form, patients had to select the type of service and time. In the new form, there is also an option for choosing the doctor. The clinic anticipates less traffic on the phone line, but it does not know if patients will be able to deal with the new additional step.

At first, the clinic shows the new form to the receptionists. They book some appointments and examine the calendar. A few patients see the new form next. The receptionist checks the calendar at the end of each day: did the appointments arrive, did the emails go out, and are people calling for help more often? The team expands the trial only when those answers look good. If the calendar starts losing appointments, the receptionist calls the release owner, who returns visitors to the familiar form.

There is a catch. Both forms must save an appointment in a way the clinic can read. If the new form writes records that the old form cannot open, flipping the switch back will leave patients in limbo. Draw the route back before the trial starts.

Why businesses use feature flags

The first benefit is a smaller release risk. If fifty people see a faulty page, staff can usually find and help them. If fifty thousand see it, the support desk may be flooded. Staff can also try the new page on the live site, where real email and payment services may act differently from a test setup.

Flags may aid companies to understand what the clients need. If a firm implements a shortened sign-up process for one cohort and compares it with the old process, a valid metric is needed for the process. However, more clicks do not indicate a good experience. Completed bookings, errors, and calls to client support might work better for a booking process.

Lastly, flags assist in coordination. The marketing department may require to roll out a promotion offer in accordance with a schedule although developers had done the coding a few days before. The feature can be deployed and tested before the launch date. The toggle will be turned on when the organization is ready to start.

There are costs too. Every active flag adds another path in the app. The team has to make sure the users know about the correct path and remove outdated flags. It is easy to overcomplicate even a straightforward product when people think flags provide permanent storage for incomplete decisions.

Choose the appropriate switch type

Every flag works in its own way. A release flag manages a new feature that is being rolled out to the customers. In general, it should be temporary. The goal of an experiment flag is to divide users between two alternatives to evaluate both ideas. It needs to have some metrics and a predetermined termination date. An operations flag turns off an expensive functionality in case of failure of the system. It will last for a while but still requires testing.

Permission flags also exist. They determine whether the customer can access the paid or private features. A permission rule needs stronger security. Knowing a page address should never grant access to private records. The server has to check the person's permission when it receives each request.

Keep the scope of a switch small. Suppose the same flag changes the booking page, the confirmation email, and a discount. Which change caused a complaint? Which one should you undo? Three separate decisions are easier to explain and retire.

Write a one-page release plan

Write a short note that a teammate can use during a busy release. Say exactly what the visitor will see, who joins the first trial, and which result would make the team stop. Put a real person's name next to the off switch. Add the day when the team will decide whether to keep the feature.

Call the flag `new_booking_form` or something equally clear. A name like `flag_17` may make sense today and puzzle the next developer in three months. Keep the owner and review day in the same place as the flag.

Now unplug the switch service in a test. What does the checkout do? A checkout form should not get stuck because of a sluggish switch provider. Most engineering groups have a safe default value close to the application, which gets updated once the flag service answers. It depends on the particular feature that determines the proper default. In case of a payment process switch, the previously tried one might work better. For an emergency operations flag, the default value can be another.

Test both states of the flag

While the flag is off, make sure the old journey still works. When the flag is on, test the new journey from a user's first click until the very end. For the clinic's case, this will include calendar entry, confirmation message, and actions of the staff at the desk. The test is complete only when a real appointment appears on the clinic calendar.

Try turning the flag while a colleague is halfway through the form, too. What happens to a person halfway through booking? Will all the inputs disappear if the form refreshes? If someone started in the old form, can they finish there? These questions matter more than the colour of a button.

A switch should not erase choices a patient has already made.

Some changes will require thorough data preparation. In the case where a new feature modifies the database structure, two versions of the application will exist simultaneously for the time being. The development crew should ensure both versions are able to access the necessary data. A switchover operation won't reverse a database modification automatically. In case of more extensive changes, programmers can migrate data gradually with a fallback option.

Roll out incrementally, but then pay attention to the right metrics

A reasonable initial release could reach the staff team, the first customer cluster, and then a second one. What matters here is not the percentages themselves but critical points in between. Spend enough time waiting to gather significant insights. If an application page works fine for twenty employees, there is no guarantee that it will function properly for a thousand active clients later.

Monitor technical metrics like errors, slow pages and failed transactions. Also look for human metrics - support cases, abandoned forms and messages from customer-support staff members. A new booking form can be technically healthy while making reception busier. That is still a problem to solve.

Have a stop rule in place before going live. For instance, the team will halt operations once there is a spike in booking failures past a certain threshold for fifteen minutes. Set a threshold that is in line with regular traffic and ensure it is visible to the person on duty. A loose guideline of “keeping an eye on it” is easy to overlook during the hustle.

Ensure the switch is safe to use

Access to change a live flag should be restricted only to the right people. A switch that determines payments and pricing is just as critical as any other production configuration. Documenting the switch changes helps the team trace what the customers saw in case there is any error.

In the case of a big organization, the person who developed the feature and the person who approves the release may not be the same. An approval step in the process prevents any unfortunate events from occurring late at night. In a smaller organization, the process can be simplified. The process includes one owner, one backup and a trigger condition for the backup to be contacted.

Verify that the switch itself is private. If the application shares all the flags and targeting rules with the browser, users might find out some secret names or future ideas. The server is responsible for making decisions regarding any sensitive functionality. A hidden screen is no lock. The server must check each request for private information.

Remove legacy flags before they cause problems

When the new booking form is adopted, the team should get rid of the old form and the switch. Keeping both forms in the product requires consideration of both forms in any future change. Months later, nobody may remember what the old form is for. A developer fixing the calendar might then have to repair two forms instead of one.

Put a cleanup date on the ticket before the trial begins. When that day comes, look at completed bookings and the receptionist's notes. If the new form helped patients, remove the old form and the flag. If it made bookings harder, remove the new form or give it another clearly dated trial. Give that cleanup task to one named person.

Once a month, look through the flags that remain. Ask the owner of each flag to tell a short story: why is it here, when was it last used, and when can it go? “We may need it someday” is too vague a reason to keep two versions of a screen.

Is a startup able to use flags without a flagging platform?

Yes. A small team can put one switch in its server settings and use it for one modest change. The team still needs to try both routes, record who changed the switch, and remove it after making a decision. A paid tool becomes useful when many services share flags or when the team must target and audit changes across several products.

Start with a search filter or another change that is easy to reverse. Time how long it takes to switch it off. Can support staff tell which version a visitor saw? Did the old route still work? Those answers are more useful than a long list of platform features when the team is deciding what to buy.

How Digitonix can help

Digitonix can help plan a safer release for an app. It may include building up a map of the customer's journey, putting in a proper switch for testing different ways, monitoring for any errors, and taking out the switch when all the rollout is complete. First of all, you need to focus on a single goal like decreasing unsuccessful bookings or improving checkout, not just a set of instruments.

For the app itself, see Digitonix's web development and mobile app development services. If you need safer releases and better monitoring tools, explore cloud and DevOps. Some examples of technologies which may fit here are Next.js, Node.js, and AWS and many others. It all depends on what product you currently have.

Questions and Answers

Is a feature flag the same as a test environment?

No. A test environment allows you to find potential problems with a new version of a product before users see it. While a feature flag enables controlling who will see a particular modification in a live product. You need both in order to release a critical update safely.

Can a flag fix a broken database change?

Rarely alone. If the new code alters any data in some manner, the older code may no longer be able to recognize it. Coordinate data changes such that both versions will function during the rollout period, and check the behavior of the product post-rollback.

How long should the release flag be part of the application?

Only for as long as the rollout decision itself necessitates it. Determine the review date at the time the flag is created. Once the release is a success, delete the old path and the switch; if not, delete the new path.

Do feature flags make release decisions risk-free?

No, although feature flags limit the size of the affected group and potentially enable a roll-back decision to be taken quickly. The team would still need good testing, monitoring, ownership, and means to resolve data or customer problems incurred prior to roll-back.

Which feature is a good choice as the first one to flag?

Select something that can be seen but is not going to be a risk. This may include a new booking layout or a search filter that can do something differently. Avoid using your first flag for a major payment or data change. Learn the release process on something smaller.