Customer Tier Enforcement: Free, Pro, Enterprise the Right Way

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.

The core argument

Customer tier enforcement is one of those engineering decisions that founders make without realizing it is a decision. The first version is a few if statements checking the plan name. The second version is a few more. The tenth version is a junction box 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

How much does this cost

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

1. Hardcoded plan name checks.
2. No central capability registry.
3. No add on or override support. Edge cases break.
4. No trial state handling.
5. No usage limit enforcement.
6. No webhook integration with Stripe. Manual sync.
7. No admin tool for overrides. Engineering escalations.
8. No audit log. Disputes follow.

A two week build plan

1. Days one to three. Design the entitlement schema. Plans, capabilities, overrides.
2. Days four to six. Build the service and the API.
3. Days seven to eight. Integrate Stripe webhooks.
4. 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.