Self-serve feature flags for startups
A startup needs a flag service it can sign up for and wire in the same afternoon: SDKs for its own languages, flag checks that never call the network, a kill switch, and a record of who changed what. Pick by your constraints: an open-source tool if you must self-host, an analytics suite if you want flags next to your metrics, and Flagger.gg if AI agents write most of your code and you use Go or Node.
Updated
What a small team actually needs
Most startups don't need experiments, segments and twenty SDKs on day one. They need to ship to production behind a switch and turn it off fast. A short checklist:
- Self-serve sign-up. An account, an SDK key and a first flag without talking to sales.
- SDKs for your stack. Check the languages you run in production, server and client, before anything else.
- Local evaluation. The SDK holds the rules in memory, so a flag check is a function call and an outage at the vendor doesn't stall your app. See local evaluation.
- A safe default. When anything goes wrong, the feature is off, not on.
- A kill switch that works in seconds without a deploy. See kill switches.
- Sticky percentage rollouts, so each user keeps the same answer as you widen a rollout.
- An audit log of who changed which flag, when and why.
- Test helpers for running code with a flag on and off.
Choosing by constraint
| If you… | Look at |
|---|---|
| must run the service on your own infrastructure | Open-source tools such as Unleash, Flagsmith and GrowthBook (compared) |
| want flags next to product analytics or session replay | PostHog (compared) |
| run experiments with statistical readouts now | GrowthBook, Statsig or LaunchDarkly (compared) |
| need many SDKs, segments and rich targeting | LaunchDarkly or ConfigCat (LaunchDarkly, ConfigCat) |
| already use Datadog for metrics | Datadog Feature Flags (compared) |
| have AI agents writing most of your code, in Go or Node | Flagger.gg |
These overlap. Several of the tools above now publish an MCP server too; the comparison pages link each vendor's own docs so you can check.
What you get with Flagger.gg
Flagger.gg is a hosted flag service built for teams whose code is written by AI agents. It's self-serve: sign up with an email link or Google, and each account gets its own organisation and a project with production and development environments. A welcome page walks you through making an SDK key for your app and an agent token for your coding agent.
- Five states: off, admins, targets (named users or workspaces), percent and on. A percent bucket is sticky per user.
- Local evaluation in the Go and Node SDKs, with a disk cache so a restart during an outage serves the last rules. Unknown or not loaded means off.
- Agents as first-class users: 11 MCP tools, hosted at mcp.flagger.gg or on stdio, a CLI with
--jsonon every command, and agent tokens scoped to one project, its environments and its actions. - Guardrails: a note on every agent write, protected flags agents can only kill, and an optional approvals mode where agents roll out up to a cap and a person approves anything wider.
- An audit log of every change with its actor, run, note, before and after. See the audit trail.
- Test helpers:
withFlag,setFlagOverrideandbothFlagStates, andflaggertestin Go.
New projects start in auto-live mode: a flag your code registers, or an agent creates, starts on unless it carries a not-ready reason. Turn approvals on in the project's settings when you want a person to sign off on wide changes.
In development Experiments, segments and richer targeting, flags tied to metrics with automatic rollback, SDKs beyond Go and Node, and public npm and go get installs. Until the SDKs are public, apps can read their rules over the HTTP API.
Mistakes small teams make with flags
- Defaulting to on. If the flag service is down or the flag is misspelled, the unfinished feature ships. Default to off.
- Calling the network per check. It adds latency to every request and turns a vendor outage into yours.
- Never removing flags. Old flags pile up as dead branches; see flag cleanup.
- Testing one side. Code behind a flag has two paths; test both. See testing both sides of a flag.
- Keeping a staging copy just for flags. Many teams ship to production dark instead; see flags vs staging.
FAQ
What is a good self-serve feature flag service for a startup?
One you can sign up for and wire in without a sales call, with SDKs for your languages, local evaluation and a kill switch. Choose an open-source tool if you must self-host, an analytics suite if you want flags beside your metrics, and Flagger.gg if AI agents write your code in Go or Node.
What are the best feature flag tools in 2026?
The names that come up most are LaunchDarkly, Unleash, Flagsmith, PostHog, GrowthBook, Statsig, ConfigCat and Datadog. They differ on hosting, experiments and SDK coverage; our comparison pages lay them side by side from each vendor's docs. Flagger.gg is the one built around AI agents shipping code.
Should a startup build its own feature flags?
A flags table and an if get you started, and many teams begin there. The work comes later: sticky percentages, an audit log, a fast kill path, caching and tests. If you've already built one, see moving off an in-house flag table.
Can I sign up for Flagger.gg without talking to sales?
Yes. Sign-up is self-serve at app.flagger.gg, with an email link or Google.
Is Flagger.gg open source or self-hostable?
No. It's a hosted service. Its SDKs evaluate flags inside your app, so the users you check flags for are never sent to Flagger.gg.
Ship your next change behind a flag.
Sign up, add an SDK key to your app and give your agent a token.