Feature Flags Architecture for B2B SaaS Products

Feature flag architecture for B2B SaaS requires a fundamentally different design than feature flags for consumer products. The targeting unit is different (accounts, not individual users), the use cases are different (plan-based gating, enterprise beta access, compliance-driven feature controls), and the evaluation logic is more complex. A feature flag system designed for B2C will create architectural debt when you try to force it into B2B use cases.

This guide covers the B2B-specific feature flag design decisions: taxonomy, schema, targeting evaluation order, and how to handle enterprise custom features without forking your codebase.

Why B2B Feature Flags Are Different

In B2C, a feature flag targets individual users or random user cohorts. In B2B, the fundamental targeting unit is the account — an organization that may have dozens or hundreds of users. A feature flag that is enabled for an account applies to all users in that account, regardless of individual user properties.

This creates design requirements that B2C flag systems don't have:

→ Account-level evaluation: The flag system must be able to evaluate flags against an account ID, not just a user ID
→ Plan-based targeting: Features must be gatable based on the account's subscription plan
→ Per-account overrides: Enterprise accounts frequently need features enabled or disabled outside the normal plan structure
→ Account inheritance: Users inherit feature access from their account; user-level overrides should be the exception, not the rule

The B2B Feature Flag Taxonomy

Four flag types cover the majority of B2B SaaS use cases:

Flag Type	Purpose	Targeting
Kill Switch	Disable a feature in production without deployment	Global (all accounts)
Plan Gate	Restrict features by subscription tier	Plan name/ID
Account Beta	Enable unreleased features for specific accounts	Account IDs list
Gradual Rollout	Percentage-based rollout to accounts	Account-level percentage

Kill Switches

Emergency toggles for features that need to be disabled without a deployment. Essential for third-party integrations that may go down, features with resource consumption issues, or features where a critical bug is discovered post-deployment. Kill switches evaluate first — if a kill switch is off, no other targeting matters.

Plan Gates

The most common flag type in B2B SaaS. A feature is available on Starter plan and above, but not on Free. Implemented by checking the account's current plan against the feature's plan requirement. Plan gates are static configuration — they don't vary by account except through the plan assignment.

Account Beta Flags

Enable unreleased or premium features for specific accounts. Use cases: enterprise pilots, early access programs, large account custom requests. Stored as an explicit list of account IDs that have the feature enabled. The list should be manageable from an admin UI without requiring a deployment.

Gradual Rollouts

Roll out a new feature to a percentage of accounts to detect problems before full release. Use account ID as the rollout hash — this ensures that all users within an account see the same feature state, and that an account doesn't flip in and out of the rollout between requests.

Schema Design for B2B Feature Flags

A practical schema for B2B feature flags:

-- Feature flag definition
CREATE TABLE feature_flags (
  key TEXT PRIMARY KEY,       -- e.g., 'ai_assistant'
  description TEXT,
  enabled_globally BOOLEAN DEFAULT false,  -- kill switch
  rollout_percentage INTEGER DEFAULT 0,   -- 0-100
  plan_requirement TEXT,                  -- 'starter', 'pro', null
  created_at TIMESTAMPTZ DEFAULT NOW()
);

-- Per-account overrides
CREATE TABLE account_flag_overrides (
  account_id UUID NOT NULL,
  flag_key TEXT NOT NULL REFERENCES feature_flags(key),
  enabled BOOLEAN NOT NULL,              -- explicit on/off
  expires_at TIMESTAMPTZ,               -- optional expiry
  reason TEXT,                          -- audit trail
  created_at TIMESTAMPTZ DEFAULT NOW(),
  PRIMARY KEY (account_id, flag_key)
);

Evaluation resolves in order: kill switch → account override → plan gate → gradual rollout → default disabled.

Enterprise Custom Features Without Codebase Divergence

Enterprise accounts frequently request features that are not in your standard roadmap. The wrong approach is to maintain a custom branch or deploy a modified version of your product for each enterprise customer — this creates immediate maintenance debt and leads to a codebase that cannot be updated safely.

The right approach: implement enterprise-specific features behind account-level flags and deploy them to all accounts. Only the enterprise account with the override sees the feature. The code ships universally; the activation is scoped.

This pattern has limits: features that require fundamentally different data models or architecture cannot easily be flag-gated. In those cases, the decision to build becomes a product decision about whether to generalize the feature for all customers rather than keeping it custom. Custom features that can't be generalized should be evaluated carefully before building.

Tooling Choices for B2B Feature Flags

→ LaunchDarkly: The enterprise standard. First-class support for account-level targeting, excellent audit logging, and SDKs for every major language. Expensive at scale; appropriate for Series B+ companies where feature flag complexity justifies the cost.
→ Unleash: Open-source, self-hostable, strong B2B targeting support. Good choice for teams that want control over their flag infrastructure and don't want to pay SaaS pricing for a SaaS tool.
→ Statsig: Modern alternative with strong experimentation and B2B entity support. Competitive with LaunchDarkly on features at a lower price point.
→ Home-built: Viable for simple use cases (plan gates + account overrides). The schema above covers 80% of B2B flag use cases. Becomes harder to maintain as you add experimentation and analytics requirements.