What a feature flag actually is doing
A feature flag is a runtime decision point: a request comes in, the flag evaluates against rollout percentage, targeting rules, or both, and the code branches. That evaluation happens on every relevant page load or event, which is why flag volume shows up directly in PostHog's usage-based pricing.
Rollout design, not just rollout percentage
- Start narrow, widen deliberately. A percentage rollout should map to actual risk tolerance and blast radius, not a round number picked because it looked reasonable.
- Targeting beats blanket percentage for risky changes. Rolling a change out to internal accounts first, then a defined beta cohort, catches more before it reaches everyone.
- Multivariate flags need a clear success metric before launch. A flag with three variants and no defined comparison metric is an experiment without a hypothesis.
Flag hygiene: the discipline that prevents debt
| Practice | Why it matters |
|---|---|
| Naming convention | A consistent flag name pattern makes stale flags findable months later |
| Owner on every flag | Someone has to be responsible for deciding when a flag is done |
| Removal as part of "done" | A rollout is not complete until the flag and its dead branch are removed |
| Periodic flag audit | Catches flags nobody remembers creating, still evaluating on every load |
Where this connects to migration and self-hosting
Teams migrating onto PostHog from another flagging tool (LaunchDarkly, Split, or a homegrown system) need flag-by-flag mapping, not a blanket re-create - see the migration hub. Self-hosted deployments also need flag evaluation volume factored into infrastructure sizing; see the self-hosted guide.