Key Takeaways

• Both checks wrap the same conditional around a code path and answer different questions: is this code safe to run for anyone yet, or has this account bought it.

• Flag tooling exists to reduce long-lived flags. Statsig defaults every new gate to Temporary and marks one stale after 30 days with zero checks, and Unleash rates technical debt as healthy flags against stale ones.

• LaunchDarkly's docs file entitlements under permanent flags, which is why teams put paid access in a flag tool and then fight its cleanup workflow.

• Source of truth is the dividing line. A flag's answer comes from a config an engineer edits, an entitlement's from the subscription a customer signed.

• A wrong flag exposes unfinished code to some users. A wrong entitlement gives paid capability away or locks out a payer.

What question does each check actually answer?

A flag answers a question about your code, an entitlement a question about a contract. They sit a few lines apart, which is why teams stop noticing they're different.

// Flag: is this path safe to run for anyone yet?
if (await client.getBooleanValue("report-renderer-v2", false)) {
  return renderReportV2(report);
}

// Entitlement: has this account paid for it?
const access = await billing.entitlements.check(account.id, "custom_reports");
if (!access.allowed) return upgradePath(access.required_plan);

What separates them at the call site:

• The subject. The flag targets a release. The entitlement targets an account, and on enterprise deals the paying parent rather than the user in front of you.

• The return shape. A flag returns a variation. An entitlement returns why it said no, so the product renders an upgrade path, not a dead button.

• The vocabulary. Feature gating enforces both, but only the billing side knows what a plan, an add-on, or past due means.

How does the lifecycle of a flag differ from an entitlement?

A flag is temporary by design and an entitlement is permanent by design, and the rest follows. LaunchDarkly puts it plainly: a temporary flag has a limited lifespan, while permanent flags keep control long after a feature ships.

Flag vendors do support long-lived flags. Flagsmith has a protected tag that blocks accidental deletion, and Statsig lets you mark a gate Permanent so it leaves the cleanup queue. Keeping a paid-access flag alive means opting out of the workflow that tool exists to run.

Which check should guard a paid feature?

The entitlement guards the paid feature. The flag sits in front of it only while the capability rolls out, and once the feature ships to everyone the flag comes out and the entitlement stays.

Every time I've seen paid access stored in the flag tool, the same problems show up:

• Pricing edits become engineering tickets, because whoever changed the price book can't write the flag config.

• The two records drift. The plan says a tier includes SSO, the flag config says otherwise, and support arbitrates ticket by ticket.

• Cleanup tooling fights you. A flag that never dies reads as debt, so someone tidying up eventually archives it.

• Nothing reconciles. You can't tie a flag flip to the invoice line it should have changed, so revenue leakage surfaces only when a customer mentions it.

Keep each record where it belongs: releases in the flag tool, paid access next to the plan. Billing platforms model entitlements as part of the plan object, and Flexprice ships them inside Usage Metering. OpenFeature, a CNCF incubating project since December 2023, standardizes the flag half behind one API, backed by LaunchDarkly, Split, CloudBees and Flagsmith.

Related terms

The neighbours worth reading next sit on either side of this split.

• Feature Gating explains how a paid-access check resolves at request time.

• Subscription Lifecycle walks the states, past due and cancelled included, that flip an entitlement answer with no config edit.

• Usage Metering supplies the counts a quantity-bound entitlement reads when access depends on remaining allowance.

• Spending Cap handles the ceiling, which an on-or-off flag can't express.

• API Monetization puts plans, keys and quotas together at the endpoint.

FAQ

Can you use LaunchDarkly for entitlements?

Yes, and LaunchDarkly documents entitlements as a permanent-flag use case. The catch is that the flag config then holds commercial data, so pricing changes route through engineering and nothing reconciles against the invoice. LaunchDarkly's own advice is to name one source of truth and pull its settings into every other system.

Are entitlements just permanent feature flags?

No. A permanent flag is one the cleanup workflow ignores, which is a property of its lifetime. An entitlement is a claim derived from a subscription, so it changes when a customer upgrades, downgrades or misses a payment.

Do you need both a flag system and an entitlement system?

Most product teams do. The flag system de-risks shipping and the entitlement system decides who pays for what. They compose at the call site: the flag opens the code path, the entitlement decides which accounts reach it.