Architecture Patterns

Feature Flags (Feature Toggles)

Term 68 of 68 in the ERPStack technical glossary

What is Feature Flags (Feature Toggles)?

Feature flags are configuration switches that enable or disable specific application features at runtime without deploying new code — enabling trunk-based development, gradual rollouts, A/B testing, and instant rollback of problematic features.

Feature Flags (Feature Toggles) at a glance

Core idea: Deploy and release become 2 separate events instead of 1
Flag types: 4 kinds: release, experiment, operational kill switch, and per-tenant entitlement
Rollout: Enable for 1 internal tenant, then a percentage, then 100% — with 1 switch to reverse
Hygiene: Release flags are temporary; a flag left in place for 2 years is Technical Debt with a config UI
Built with: Flag evaluation in Next.js 16 and React 19 server components, state in PostgreSQL 18 via Drizzle ORM 0.45, releases driven by GitHub Actions to Vercel or AWS, regressions surfaced in Sentry
Numbers that matter: 2 separate events, deploy and release; 4 flag types; 1 switch to reverse an incident; 1 owner and 1 expiry per release toggle
Compare with: Long-lived Git branches, 1 code fork per customer in B2B Software, or Zoho Creator and Monday.com configuration toggles
Commonly paired with: CI/CD Deployment Pipelines on GitHub Actions, Multi-tenant Architecture entitlements, PostgreSQL 18 flag state via Drizzle ORM 0.45, Next.js 16 server components, Vitest 4 and Playwright 1.59 coverage, and Sentry regression alerts
Test matrix: 2 active flags mean 4 code paths; Vitest 4 and Playwright 1.59 cover the 2 that ship, not all 4
Where the state lives: Flag state in PostgreSQL 18 through Drizzle ORM 0.45, evaluated in Next.js 16 and React 19 server components, released by GitHub Actions to Vercel or AWS, regressions caught in Sentry.
Where they pay off: SaaS and Multi-tenant Architecture products in finance, healthcare and retail, where 1 tenant needs a capability 3 months before the rest are ready for it.

How Feature Flags (Feature Toggles) works in production

In large ERP teams, deploying untested features to all users simultaneously is risky. Feature flags allow features to be deployed in a 'dark' state, then gradually enabled for specific user segments (e.g., beta customers, specific tenant IDs). If a bug is detected, the flag is toggled off in seconds — no code redeployment required. Feature flags are a prerequisite for continuous deployment in regulated environments where rollback capability must be demonstrated.

The ERPStack approach to Feature Flags (Feature Toggles)

We implement feature flag infrastructure using LaunchDarkly or open-source Unleash, integrated with our PostgreSQL tenant tables so flags can be enabled per-customer with zero code changes.

Related Resources

Frequently asked questions about Feature Flags (Feature Toggles)

What do Feature Flags actually decouple?

Deployment from release. With Flags in place, code ships to production in a disabled state, so the risky moment is a configuration change rather than a deploy. That lets teams merge continuously instead of maintaining long-lived branches, and it turns an incident response from an emergency rollback into flipping 1 switch — which is faster and far less likely to cause a second problem.

How do Feature Flags differ from A/B tests?

By intent, though the mechanism overlaps. Release Flags exist to control exposure and are removed once a feature is fully live. Experiment flags exist to measure a difference between variants and need statistics to conclude anything. Operational kill switches are permanent by design. Confusing the 3 is how teams end up with hundreds of stale toggles nobody dares delete.

What is the hidden cost of feature flagging?

Combinatorial state. Every active toggle doubles the number of code paths in theory, and Flags left in the codebase after launch make behaviour hard to reason about and hard to test. The discipline that keeps this manageable is an owner and an expiry on every release toggle, plus removal being part of the work rather than a follow-up ticket nobody schedules.

How do Feature Flags help multi-tenant products?

They make per-customer variation data instead of code. Entitlement Flags let 1 shared codebase enable a capability for specific tenants, which is how B2B Software supports genuine customer differences without forking. That is strictly better than a branch per customer: 1 deployment, 1 test suite, and a capability matrix that can be inspected rather than inferred from git history.