Once SaaS teams accept that billing is not access control and pricing is not enforcement, a practical question immediately follows:
Where should entitlements actually live in a SaaS system?
This is where many teams stall.
They agree entitlements matter, but aren’t sure whether they belong:
in the billing provider
in feature flags
in the database
inside application code
or spread across all of the above
This article gives a clear, opinionated answer and shows how mature SaaS systems structure entitlement logic so it scales with pricing, customers, and product complexity.
The core principle: entitlements belong to the product domain
Entitlements should live inside your product, not inside your billing provider and not hidden in conditional logic.
They are part of your business domain, just like users, accounts, and permissions.
That means:
your application owns entitlement state
your database persists entitlement decisions
your product logic enforces them consistently
External systems — including billing tools — should only inform this state.
The common (but broken) alternatives
Before outlining the right approach, it’s useful to see why the usual alternatives fail.
Option 1: Entitlements inside Stripe
Some teams attempt to infer access directly from:
subscription status
price IDs
metadata fields
This creates:
tight coupling to billing internals
race conditions via webhooks
brittle pricing changes
Stripe is an event source — not an access authority.
Option 2: Entitlements as feature flags
Feature flags are excellent for:
rollouts
experimentation
kill switches
They are not designed for:
quotas
limits
long-lived access state
customer-specific exceptions
Using feature flags as entitlements results in opaque, unmaintainable logic.
Option 3: Entitlements as hard-coded plan checks
Early-stage code often looks like:
This breaks immediately when:
plans change
customers are grandfathered
sales makes exceptions
Hard-coded plans turn pricing into a permanent constraint on engineering.
The correct model: a dedicated entitlement layer
Mature SaaS systems implement entitlements as a first-class layer.
Conceptually:
Billing systems emit events
Pricing defines mappings
Entitlements store decisions
The application enforces rules
Entitlements become the single source of truth for access.
What an entitlement layer actually contains
A real entitlement system is not a single boolean.
It typically stores:
feature access flags
numeric limits (seats, usage, quotas)
consumption counters
expiration timestamps
override reasons and sources
For example:
This state is:
explicit
inspectable
auditable
enforceable at runtime
Where this lives technically
In practice, entitlements usually live:
in your primary application database
keyed by account or organization
versioned or timestamped
They are queried:
on API requests
during UI rendering
at usage checkpoints
They are not recalculated on the fly from billing state.
How billing integrates without owning access
Billing systems like Stripe should:
trigger entitlement updates
never be queried synchronously for access
A typical flow:
Billing event occurs (upgrade, cancel, payment failure)
Webhook arrives
Entitlement update logic runs
New entitlement state is persisted
From that point on, the application relies only on stored entitlements.
This removes:
webhook timing risk
external dependency latency
access flapping
Why pricing becomes safer with this approach
When pricing changes:
entitlement mappings change
historical entitlements remain valid
legacy customers stay correct
Because pricing definitions are decoupled from enforcement, experimentation becomes low-risk instead of terrifying.
Organizational benefits
Clear entitlement ownership simplifies collaboration:
Product defines capabilities
Growth experiments on pricing
Finance owns billing
Engineering enforces access
Each team moves independently without stepping on the others.
When teams usually realize they need this
Most companies reach this conclusion when:
enterprise deals appear
support load spikes
pricing changes slow releases
billing bugs reach customers
Unfortunately, that’s also when refactors are most painful.
Building an entitlement layer early pays off disproportionately.
Final takeaway
Entitlements are part of your product, not your billing stack.
They should:
live in your application domain
be stored explicitly
be enforced consistently
Billing tools inform entitlements. Pricing defines them.
Your product enforces them.
Get this boundary right, and your SaaS architecture can scale without fear.