Customers should not be your QA environment. Feature flags and dark launches let engineering turn code on for 1% of traffic, one tenant, or only staff — while the marketing site looks unchanged.
This is release engineering customers never see, but it decides whether a Friday deploy becomes an incident.
Feature flag vs config vs branch
A flag is a runtime decision: who sees which code path. Config is static behavior. Branches are for incomplete work not ready to merge. Long-lived flag-less branches are how merges go bad; long-lived uncleared flags are how codebases rot.
Dark launch pattern
1. Ship the new path behind a flag defaulted off.
2. Run it in shadow mode: compute results, log diffs, do not affect user output.
3. Enable for internal users.
4. Ramp percentage or tenant allowlists.
5. Remove the old path and the flag once stable.
Shadow mode is especially valuable for pricing, ranking, and recommendation changes.
Targeting rules that matter for agencies and SaaS
- Environment: staging always on for QA.
- Role: staff / impersonation only.
- Tenant ID: pilot clients.
- Percentage rollout with sticky bucketing by user ID (not random per request).
- Kill switch: global off that does not require a redeploy.
Implementation notes for Next.js and Node
Evaluate flags as close to the decision point as possible, but cache evaluations per request. Do not fetch flags on every tiny component without a request-level cache.
For SSR, ensure the flag snapshot is consistent across a single HTML response to avoid hydration mismatches. Send a bootstrapped flag map to the client when UI depends on it.
Observability around flags
Log `flag_key`, `variant`, and `reason` on error reports. When something breaks, you must know which cohort was live. Pair ramps with latency and error-rate burn alerts.
Flag hygiene (the part teams skip)
Treat flags as temporary debt:
- Ticket to remove within 14–30 days of full rollout
- Naming convention: `ff_<area>_<change>`
- Archive dead flags in the provider
- Never reuse flag keys for a new meaning
Anti-patterns
- Using flags as permanent multi-tenant configuration (use a settings model instead)
- Coupling ten flags into one deploy with no ramp plan
- Storing PII inside flag payloads
- Client-only flags for security-sensitive authorization (always enforce on server)
Final takeaway
Feature flags are invisible development infrastructure. Done well, customers only notice a smoother product. Done poorly, they become permanent mystery branches in production.