Feature flags in Lovable and Supabase apps
How a team ships code on Tuesday and turns the feature on for customers on Thursday, or off again in seconds.
In short
A feature flag is a switch in an application's configuration that turns a feature on or off, for everyone or for chosen users, without deploying new code. Teams use feature flags to release gradually, test with a few customers first, and switch off a misbehaving feature in seconds instead of rolling back a whole release.
Also called: Feature toggle, Feature switch
How do feature flags separate shipping code from releasing it?
Without flags, every release is all or nothing: a feature is live for everyone the moment it deploys, and the only way to stop it is another deploy. Flags separate the two decisions, shipping code and exposing it, which makes releases smaller and incidents shorter.
What are the four kinds of feature flag?
Pete Hodgson's widely cited article sorts flags into four categories: release flags for unfinished work, experiment flags for A/B tests, ops flags such as kill switches, and permissioning flags that give features to some users only. Each kind lives for a different length of time, from a week or two to years.
Why should every feature flag have a removal date?
Flags are code paths, so each one adds conditional logic and testing burden. Hodgson's article advises treating flags as inventory to keep low: add a removal task when a release flag is created, and set expiry dates. Some teams add a test that fails once a flag is past its date.
How long a flag lives depends on its kind. Release flags usually last a week or two; experiment flags stay until the results are statistically significant; permissioning flags can last years. Test the release in both states, at least the expected production setting and the fallback with new flags off.
How do you add feature flags to a Lovable and Supabase app?
If you keep flags in a Supabase table, treat that table like any other data. Supabase's documentation warns that a table in an exposed schema without row-level security is readable and writable by any role with a grant on it, and says to enable RLS on every such table, so write policies that let only admins change a flag.
- Default every new flag to off, so the old behavior is what runs if the flag is missing.
- Give each one an owner and a removal date.
- Wrap risky integrations, such as AI calls or payments, in an ops flag that works as a kill switch during incident response.
- Merge unfinished work behind a release flag rather than keeping a long-lived branch, so your CI/CD pipeline tests it every day.
If you outgrow a table, OpenFeature is an open specification that gives one vendor-agnostic API for feature flags, with providers translating it to whichever flag service you use. Our production readiness check asks whether you can switch off a failing feature without a release.
Common questions
Do I need a feature flag service?
Not at first. A few flags in configuration or the database are enough. A service helps once you target segments or run experiments. Whichever you use, give each flag an owner and a removal date, and delete release flags once the feature is fully on.
What is a kill switch?
A kill switch is a long-lived ops flag that turns a feature or an integration off instantly when it misbehaves in production, ideally without a new release. It avoids rolling back a whole release while the cause is found. In Bell, every AI call passes an off switch first.
What is the difference between a feature flag and a feature branch?
A feature branch keeps unfinished code apart in version control until it merges. A feature flag merges the code into the main branch but keeps it switched off in production. Martin Fowler's continuous integration guide prefers flags, because the code is integrated and tested with everything else every day.
Go deeper
How to test an AI-built app before launchHow to test a Lovable or AI-built app before launch: which journeys to test first, two-account access checks, payment failures, and tests on every change.
Related terms
Read next
Sources
- Supabase docs: Row Level Security
- Pete Hodgson on martinfowler.com: Feature Toggles (aka Feature Flags)
- OpenFeature documentation: Introduction
- Martin Fowler: Continuous Integration
- Microsoft Azure Well-Architected Framework: Architecture strategies for safe deployment practices
Sources checked October 24, 2026
More on this: Production architecture & security · All glossary terms
Built something in Lovable you want people to rely on?
We are the engineers who take it the rest of the way — secured, tested, released and supported.
