Customer Tier Enforcement: Free, Pro, Enterprise the Right Way
Customer tier enforcement is the system that controls which features a customer can access based on the plan they pay for. Done well, it is a centralized declarative system that the rest of the application queries. Done badly, it is scattered if statements that break every time pricing changes. The right architecture scales with the pricing model and supports the inevitable changes.
What you actually need to know
- Centralize tier enforcement. Avoid scattered plan name checks.
- Key on capabilities, not plan names.
- Include plans, add ons, overrides, trials, and limits.
- Read from Stripe via webhooks. Application reads from the entitlement system.
- Pricing changes. Build for evolution from the start.
Pattern
Maintainability
Hardcoded plan checks
Worst
Database flag per feature
Better
Centralized entitlement service
Best
Third party entitlement platform
Good with vendor lock
The core argument
Customer tier enforcement rarely feels like a decision the first time it gets made. The first version is a few if statements checking the plan name. The second version is a few more. The tenth version is a tangle of plan checks scattered across the codebase. Every pricing change becomes a refactoring project.
The fix is centralization. The application asks the entitlement system whether a customer can access a feature. The entitlement system answers based on the customer's plan, add ons, overrides, trial state, and usage. The application code does not know about plans. The entitlement system is the only thing that knows about plans.
The architecture is straightforward. A table mapping plans to capabilities. A table of customer specific add ons and overrides. A function that takes a customer and a capability and returns whether access is allowed. The application calls the function. The function handles the complexity.
The teams that adopt this from day one ship pricing changes in hours. The teams that scatter plan checks ship pricing changes in weeks because every change requires finding and updating every check. The compounding effect over years is the difference between a pricing system that supports business needs and one that fights them.
The architecture
Layer
Responsibility
Stripe
Source of truth for what customer is paying for
Webhook handler
Updates the customer's plan in the entitlement system
Entitlement system
Plans, add ons, overrides, trials, limits
Entitlement API
can this customer do X?
Application
Calls the entitlement API. Does not know about plans.
Admin tool
Adjust overrides for specific customers
How much does this cost
Approach
Build cost
Ongoing maintenance
Hardcoded plan checks
Hours initially, weeks to refactor later
Painful
Database flag per feature
A few days
Modest
Centralized entitlement service
Two weeks
Light
Third party platform
A sprint to integrate
Vendor subscription
Features the enforcement must have
- Centralized capability check.
- Mapping of plans to capabilities.
- Add ons and overrides per customer.
- Trial state handling.
- Usage limit enforcement.
- Stripe webhook integration.
- Admin tool to adjust overrides.
- Audit log on every entitlement change.
Expert opinion
Centralized entitlement is one of those engineering investments that founders skip because the first version of the product does not need it. By the third pricing change they wish they had built it. The cost of the centralized version is two weeks. The cost of refactoring scattered checks is months. The early investment compounds across every pricing change for the life of the product.
Yashveer Singh, founder of Yashveer Labs
How this played out on a real project
A SaaS client was on their fourth pricing change in eighteen months. Each change required engineering work in many places. The team had hardcoded plan name checks throughout the codebase. The latest change was estimated at four weeks of engineering work.
We rebuilt the enforcement as a centralized entitlement service. Capabilities were named. Plans mapped to capabilities. The application called a single check function. The build took two weeks.
The pricing change that had been estimated at four weeks shipped in two days against the new system. The next pricing change six months later took half a day. The pricing model has continued to evolve without significant engineering cost. The investment paid back on the first change.
For more on the related work, see plan upgrades and downgrades a billing architecture story and the SaaS refund workflow a quiet source of engineering debt.
Common mistakes teams make
- Hardcoded plan name checks.
- No central capability registry.
- No add on or override support. Edge cases break.
- No trial state handling.
- No usage limit enforcement.
- No webhook integration with Stripe. Manual sync.
- No admin tool for overrides. Engineering escalations.
- No audit log. Disputes follow.
A two week build plan
- Days one to three. Design the entitlement schema. Plans, capabilities, overrides.
- Days four to six. Build the service and the API.
- Days seven to eight. Integrate Stripe webhooks.
- Days nine and ten. Migrate scattered checks to the centralized API. One surface at a time.
For more on the related work, read plan upgrades and downgrades a billing architecture story and the subscription billing stack in 2026. On the broader architecture side, SaaS multi tenancy patterns database per tenant vs shared schema is the natural next read.
FAQ
Frequently asked
- What is the worst tier enforcement pattern?
- What is the right pattern?
- What goes into the entitlement system?
- How do I handle usage limits?
- Should I build this myself?
- How does this interact with Stripe?
- What is the most common mistake?
Author
Why I am built for this project type
I have worked on five production systems before turning eighteen. That is not a flex. That is a statement of capability. Yashveer Singh, founder of Yashveer Labs. The work in this article is the work I do on a weekly basis. If you are facing the problem I just described, I do not need to be sold on solving it. I need to be told the constraints.