- A feature flag lets you deploy code with a feature switched off, then turn it on for chosen users, teams or a percentage of accounts.
- Use flags for gradual releases, kill switches, experiments and beta programs, and give each one an owner and an expected end date.
- Store which users got a feature, so the same person sees the same version on every visit.
- Evaluate flags on the server and define a safe default in code, so a flag outage never breaks the app.
- Remove release flags from the code once a feature is fully live; old flags are technical debt.
What is a feature flag, and when does a web app need one?
A feature flag is a switch in your code that decides, at runtime, whether a user sees a feature. It lets you deploy new code with the feature turned off, then turn it on for your own team, a few customers or a percentage of accounts, and turn it off again without a new deployment if something goes wrong. A web app needs flags once releases carry real risk: paying customers, changes to billing or data, or a feature you want to test with a small group before everyone gets it.
Flags separate deploying code from releasing a feature. That makes releases smaller and calmer, which is a large part of how our SaaS and MVP team ships changes to live products.
What can you use feature flags for?
Unleash, an open source flag platform, groups flags by purpose and gives each type an expected lifetime, after which the flag is marked as potentially stale. The types are a useful checklist even if you use a different tool.
| Type | Used to | Expected lifetime |
|---|---|---|
| Release | Release new or unfinished features gradually | 40 days |
| Experiment | Run A/B or multivariate tests | 40 days |
| Operational | Switch between technical implementations with low risk | 7 days |
| Kill switch | Turn off a feature or degrade gracefully | Permanent |
| Permission | Give access by role or entitlement, such as a beta group | Permanent |
| Sunset | Plan the removal of an existing feature | 90 days |
The point of the lifetimes is that most flags are meant to be temporary. Only kill switches and permission flags are designed to stay.
How does a gradual rollout work in practice?
Every flag check has a scope: usually the signed-in user, sometimes a team or company account. In Laravel Pennant, the first time a flag is checked for a user the result is stored, and later checks read the stored value instead of invoking the rule again. That matters more than it sounds: a user who got the new checkout yesterday must not get the old one today.
A typical rollout follows the same steps whatever the tool:
- Your own team first. Turn the feature on for internal accounts and use it for real work.
- A small random share. Pennant's examples give everyone else the feature by lottery, for instance one user in a hundred.
- By account, not only by user. In business software, roll out per team or company, so colleagues see the same screens. Pennant's documentation shows a billing change rolled out to whole teams, with newer teams first.
- Everyone. Turn it on for all users, then clean up.
Watch errors and support tickets between each step. Our guide to monitoring a production web app covers the alerts worth having in place before you widen a rollout.
How do kill switches help when something breaks?
A kill switch is a flag you can turn off without a deployment. If a new feature starts failing, you switch it off, and users go back to the old behaviour while you fix it. Pennant documents a pattern for exactly this: an in-memory check that runs before the stored value, so you can disable a new API for everyone except internal team members, fix the bug, and re-enable it for the users who already had it.
Kill switches are also worth keeping around features that depend on outside services, such as a payment provider or an AI API, so a failure there can be contained by switching one feature off instead of taking the app down.
Should you build flags yourself, use a package or pay for a service?
- A package in your framework. Pennant stores resolved flag values in your relational database by default, or in memory with its array driver. It is a good fit for a single Laravel app where developers manage the flags.
- A hosted or self-hosted flag service. Tools such as LaunchDarkly and Unleash add a dashboard, targeting rules, audit history and SDKs for several languages. LaunchDarkly supports boolean, string, number and JSON flags, with JSON flags limited to 32KB.
- A hand-made table of switches. Fine for a handful of on/off settings, but it lacks stored per-user results, percentage rollouts and history, which is usually what you end up needing.
Whatever you choose, evaluate flags on the server. Unleash recommends server-side evaluation so that user details used for targeting, such as emails or locations, stay inside your application. Also give every flag a safe default in code, so the app still works if the flag system is unreachable. In a Laravel stack, our Laravel development team usually starts with Pennant and moves to a service only when non-developers need to manage flags.
How do you stop old flags turning into technical debt?
Each flag adds a second code path that someone has to understand and test. Unleash's advice is to treat flags like technical debt and plan their removal into normal sprint work. In practice that means three habits:
- An owner and an end date for every release flag, written where the team will see it.
- Remove the code before the flag. LaunchDarkly warns that if your app evaluates a flag after it is archived, it serves the fallback value defined in your code, so delete the flag checks first.
- Clear stored values. In Pennant, purge a feature's stored values once it has been removed from the app, or when you change its rules and want everyone to get the new result.
Flags work best alongside a deployment pipeline that ships small changes often; our guide to CI/CD for small teams explains that side. For custom platforms, flag clean-up is part of the regular maintenance we plan with clients in our custom software projects.
Frequently asked questions
Do feature flags slow the app down?
Not noticeably when they are set up well. Checks run on the server, results are cached for the request, and flag values for a list of users can be loaded together instead of one query per user. If a check calls a remote flag service every time, it adds a network request, which local evaluation in an SDK or a cache avoids.
Can someone without a developer turn a flag on?
With a hosted flag service, yes: product managers and support staff can switch flags and change targeting in its dashboard, with an audit history. With a package inside your own code, you either build a small admin screen for it or ask a developer to run the change, so plan which of the two your team needs before you start.
Are feature flags the same as A/B testing?
No. A flag decides who sees which version; an A/B test also needs a clear metric, enough traffic and time to compare the versions fairly. Flags are the delivery mechanism many tests use. If your app has little traffic, a staged rollout watched closely is often more useful than a formal test.
Should paid plan features be controlled by flags?
Flag tools do support permanent permission flags, and they work for beta programs and early access lists. For features that depend on what a customer pays for, most teams keep the rule in their billing and permissions logic instead, because it has to stay correct for years and match invoices and contracts.
What happens to users if the flag service goes down?
Each check falls back to the default value written in your code, so users get either the old behaviour or the new one, depending on what you chose. That is why every flag needs a deliberate, safe default, and why server-side SDKs that keep the last known rules in memory are worth using.
Last updated