AI-native
Should you build your own feature flags or use a service?
Build your own when you have one app and a few flags: a database table and an admin page are fine. Use a feature flag service once you need changes to reach every running app in seconds, sticky percentage rollouts, a kill switch that works when everything else is broken, an audit log, or AI agents changing flags safely.
Updated November 12, 2026
What does a feature flag service actually do?
Flagger.gg's guide to what a feature flag service is breaks it into four parts:
- A store of flags and their rules, per environment.
- Ways to change them: a console, an API, often a CLI, and for agents an MCP server.
- Delivery to your apps: SDKs that fetch the rules and keep them current, usually over a stream with polling as a fallback.
- A record of changes: an audit log of who changed what, when and why.
For the basics, read what a feature flag is.
When is a database table enough?
For one app with a few flags that people flip by hand, a table and an admin page work. The flag service at the heart of Flagger.gg began that way: it grew out of the flag system that runs Sandboxer and Transformer in production.
When do you outgrow it?
The guide lists the points where a homemade table stops being enough:
- changes need to reach every running instance in seconds, not on the next deploy or cache expiry;
- you want sticky percentage rollouts, where each user keeps the same answer as you widen; see how to plan a percentage rollout;
- you need a kill switch that works when the rest of the admin is broken;
- someone asks "who turned this on?" during an incident;
- several apps or teams share one set of rules;
- AI agents change flags, which needs scoped permissions and a record of which agent run made each change.
What should you check before picking a service?
- SDKs for the languages you run. Flagger.gg has Go and Node; browser/React, Python and mobile SDKs are listed as in development.
- Where evaluation happens, and what happens when the service is down. Flagger.gg's SDKs evaluate in your app from rules in memory, keep the last rules on disk, and treat anything unknown as off, so user ids and emails stay in your app.
- Hosting: hosted, self-hosted or both. Flagger.gg is hosted only and isn't open source.
- Experiments and metrics, if you want flags tied to results. On Flagger.gg those are in development.
- Access for agents: an MCP server, a CLI with JSON output, and tokens you can limit.
How do you move off a homemade table?
Flagger.gg's guide to moving off an in-house flag table describes four steps: import the flags with their history, run both systems side by side in shadow mode to compare answers, cut over, then clean up. For keeping AI-written code behind declared flags once you've switched, see typed feature flags.
Frequently asked questions
Is a database table enough for feature flags?
For one app and a few flags, yes. Move to a service when you need changes in seconds everywhere, sticky rollouts, a reliable kill switch, an audit log or agents changing flags.
What happens to my app if the flag service goes down?
With local evaluation, checks keep working from the rules already in memory. Flagger.gg's SDKs also keep the last rules on disk for restarts, and anything unknown is off.
Does a feature flag service see my users' data?
Not if flags are evaluated in your app. Flagger.gg's SDKs evaluate locally; the service stores only the targeting lists you enter.
Can I self-host Flagger.gg?
No. Flagger.gg is a hosted service and isn't open source.