Feature Flag

Feature flags are how mature teams ship new designs to production without showing them to production users. The code deploys. The experience stays hidden until the right person flips a switch. This simple idea removes the fear from continuous deployment and gives designers the ability to test on real production data with real production consequences at almost zero risk.

The mechanics are straightforward. An engineer wraps your new component or page or flow behind a call to a flag service. LaunchDarkly. Statsig. Unleash. Even a homegrown solution using environment variables can work in a pinch. When the page loads the service checks the current user against the rules you set. Is this user on the design team. Do they have an email at brainy.papers. Are they in the 2 percent rollout cohort. The answer decides which code path executes. Old path or new path. The user never knows a decision happened.

This approach solves the exact problem the dev staging production article talks about. Staging never perfectly matches production. Data is always a little off. Third party services behave differently. Performance characteristics lie. Feature flags let you bring staging into the production environment itself. Your new design runs on the same servers the CEO uses to close million dollar deals. The only difference is a config value.

What a feature flag is not matters just as much. It is not a substitute for thoughtful design systems or proper QA. It is not an excuse to leave messy code in the main branch forever. It is not the same thing as a preview deployment which exists only for the team to review. It is not a replacement for talking to users. And it is definitely not something you should use to slowly roll out a terrible idea hoping nobody notices.

Concrete example time. In early 2025 Figma wanted to ship a major update to their auto layout engine. The changes were deep. They affected every frame in every file. Instead of hoping staging caught every case they used a feature flag called auto-layout-v4. First the entire Figma staff got it. Designers immediately started opening their most complex client files in production and found three crashes within the first hour. Fixes deployed. Flag stayed. Next they opened it to power users who had opted in through their beta program. Real usage data poured in. One designer noticed that nested auto layouts with variables caused unexpected spacing. Another fix. Another deploy. By the time they rolled it to all users the feature had been battle tested against millions of real files. The old engine remained available as a fallback until they finally removed the flag three months later.

Another example comes from Shopify. Their 2023 checkout redesign touched every merchant's money. They used flags to serve the new checkout to 1 percent of stores first. Designers could log in with merchant accounts that had the flag enabled and see exactly how their new upsell components looked with real products real prices real tax rules. When they saw that the new trust badges looked tiny next to Japanese yen amounts they fixed it in code and the change applied instantly to everyone with the flag on. No waiting for the next staging cycle. No hoping the data in staging matched reality.

A third example is how Slack rolled out their new sidebar in 2024. The redesign changed muscle memory for millions of users. They started with an internal flag for Slack employees. The design team used it daily in their real workspaces. They caught that the new collapsed state hid important unread indicators for channels with long names. They fixed it. Then they expanded to 5 percent of customers. Monitoring dashboards showed a spike in navigation related support tickets so they paused the rollout adjusted the design and tried again. This iterative approach on real data is impossible without flags.

Use feature flags when the downside of being wrong is expensive. New pricing page that could tank conversions. New auth flow that could lock users out. New mobile navigation that millions of people will use. Use them when you want honest metrics instead of staging approximations. Use them when your company has grown past the point where every employee can be on the beta list. Use them to separate deploy from release so marketing launches can happen on a schedule independent of engineering deploys. Use them when you need to test with real sensitive data but cannot risk exposing it to the entire user base.

Do not use them for everything. Small CSS changes do not need a flag. Internal tools that only three people use do not need a flag. If your team cannot agree on a naming convention and ownership model for flags then do not adopt them yet. Badly managed flags create more confusion than they solve. The cognitive load of remembering which flag controls which part of the UI will make your engineers hate you. Do not use flags as a crutch for designs that are not ready for scrutiny. If the design has obvious flaws fix them before you hide behind a flag.

Teams that master feature flags operate on a different level. They deploy ten times a day. They test on real data. They roll back in seconds instead of hours. Designers spend their time perfecting experiences instead of praying that staging looked enough like production. The flag becomes the ultimate collaboration tool between design and engineering. It turns the entire production user base into a potential test group while keeping risk low. It lets you be wrong in public but only to a small controlled audience.

Feature flags turn production into the safest place to test your boldest ideas.