Feature flags in practice

Ship code before it is ready to show, roll out gradually, and turn things off instantly. Flags in the real world.

Engineering

Engineering

Decouple deploy from release

Shipping code and releasing a feature should be two separate choices.

Feature flags let us merge and deploy safely, roll a feature out to a few users first, and kill it instantly if something is wrong, without another deploy.

Control that lowers the stakes

Ship dark

Merge and deploy code before it's ready to show.

Gradual rollout

Reveal to 1%, then 10%, then everyone, at your pace.

Instant off

Kill a feature in seconds if something looks wrong.

Why they help

Separate shipping code from releasing it

The riskiest moment is turning something on for everyone at once.

Deploying and releasing don't have to be the same event. Feature flags let code reach production dark, then switch on for a few users, then more, then everyone, turning a big-bang launch into a dial you control.

If a flag reveals trouble, you turn it off instantly, no redeploy required. That safety net is what makes shipping often feel calm instead of nerve-wracking.

Highlights

What flags give us

Safe merges

Unfinished code ships dark.

Gradual rollout

A few users first, then everyone.

Instant off

Kill a feature without a deploy.

In practice

Flags are for shipping, not for hiding

The healthiest way to think about a feature flag is as a release valve: it decouples deploying code from exposing it, so engineering can merge continuously while product decides when users see the result, two schedules that were never meant to be welded together.

Real-world flags carry rollout brains: percentage ramps, tenant allowlists and instant kill switches. Shipping to 1% of traffic for an afternoon answers questions no staging environment can, at a risk small enough to sleep on.

The discipline is in the funeral. Every flag gets an owner and an expiry the day it is born, and removing a stale flag counts as shipping. Codebases with a hundred forgotten toggles are not flexible, they are haunted.

Team for AppsProduct & Engineering

We build software for teams who want their tools to fit the way they actually work — web, mobile, AI and the systems that tie them together. We write here about what we learn shipping it.

Have a project in mind?

Tell us what you're building and we'll get back to you within one business day.