5
DevOps
Build our own feature flags or buy a flag platform?
Control ↔ Time to value
Context
Move from env-var toggles to real feature flags with gradual rollouts.
Our "feature flags" are environment variables, so every toggle is a deploy. We want percentage rollouts, per-customer targeting and a kill switch that product managers can flip.
A table plus a small SDK looks like a weekend project. The flag platforms cost $300–1,000/month at our size and add a vendor to the request path.
Has anyone regretted building their own?
Constraints
- Team
- 12 engineers
- Flags
- ~60 active
- Budget
- $600/month
Build in-housevsBuy a platform
Community verdict
Build in-house 38%Buy a platform 62%
8 engineers · 4 opinions
With these constraints, what would you choose?
One choice per engineer. You can change it any time.
Build in-house
Buy a platform
Time to value →
Trade-offs
Dimensions
Build in-houseBuy a platformout of 5
- Time to value
- 2Build in-house scores 2 of 55Buy a platform scores 5 of 5
- Cost
- 4Build in-house scores 4 of 52Buy a platform scores 2 of 5
- Targeting
- 2Build in-house scores 2 of 5
Community discussion
4 comments
Have you made this decision in production? Share your reasoning.
Sign in to commentWe built ours. Version 1 took a weekend. Then came audit logs, scheduled rollouts, stale-flag cleanup, consistent percentage bucketing, a UI for PMs and an outage when the flag service was down. We bought a platform 18 months later.
Consistent bucketing bit us too: users flickered between variants because we hashed the session ID, not the user ID.
Whatever you choose, evaluate flags locally in the SDK with a cached ruleset. A remote call per flag check is how a flag vendor ends up in your incident report.
Middle ground: an open-source flag server (OpenFeature-compatible) self-hosted next to your API. You get the SDKs and UI without per-seat pricing, and you can switch to a vendor later without touching call sites.