Key Takeaways

• A feature gate answers one question at request time: is this customer entitled to this capability right now. The answer comes from their plan and billing status, not from application code.

• Feature flags and feature gates look identical in code and differ in ownership. A flag is temporary and engineering owns it. A gate is permanent and pricing owns it.

• A gate returns a boolean. A meter returns a count. Teams that conflate the two either block paying customers or give away paid capacity.

• Gates that read a cached plan ID go stale on upgrade, so a customer who just paid still sees a locked button.

• Rules stored in application code turn every packaging change into a deploy. TestZeus moved its rules into the billing layer and its GTM team configured 15 trials with zero engineering involvement.

What does a feature gate check at request time?

A gate resolves one boolean for one feature key against one customer, and everything it reads is input to that boolean. The check sits on the request path, so it answers in single-digit milliseconds or it becomes a latency problem.

The inputs a gate reads:

• The feature key. A stable identifier for the capability, not a UI element. sso, custom_reports, api_access.

• The account identity. Which customer, and which parent account pays when the two differ.

• The active subscription and its plan, which is what maps tiers to feature keys.

• Add-ons and per-customer overrides. Enterprise deals routinely open one feature outside the standard tier, and the gate honors that without a code change.

• Billing status. Trialing, active, past due, and cancelled produce different answers for the same plan.

• Remaining allowance, for features that are quantity-bound rather than on or off.

A useful gate returns more than a boolean, because the product has to render an upgrade path and not just a locked door:

{ "feature": "custom_reports", "allowed": true, "source": "plan:growth", "limit": 50, "used": 41, "resets_at": "2026-09-01T00:00:00Z" }

Keep the check on the server. A gate enforced only in the browser hides the button and leaves the endpoint open: client code decides what to render, never what to allow. Where the limit depends on consumption, the gate needs real-time metering behind it.

How is gating a feature different from metering usage of it?

Gating decides whether a customer can call something. Metering counts how many times they did. They run on different paths and they fail in different ways.

Most gated capabilities need both. The gate opens the door, and each usage event behind it feeds the meter that prices it. What happens at the ceiling belongs to spending caps, not to the gate.

Who owns the gating rules after pricing changes?

Whoever can edit the plan owns the gating rules, and on most teams that ends up being engineering by accident rather than by decision. Pricing changes, product doesn't, and the mismatch shows up as a support ticket.

Where the rules live decides who can change them:

• In application code. A map from plan ID to feature list, checked inline. Fast to write, and every packaging change after that needs a pull request and a deploy.

• In a feature-flag tool. Engineering already owns the tool, so the rules land there by default. Flags then drift from plans and the list stops describing what customers bought.

• In the billing system, next to the plan. One object defines what a tier costs and what it includes, so a packaging change is an edit rather than a release.

Flexprice is enterprise-grade, open source usage based billing infrastructure for AI and SaaS companies. It can be deployed in your own VPC, on-prem, or on Flexprice's managed cloud. Entitlements ship inside Usage Metering, so the gate reads the same plan object the invoice reads and limits change without a deploy. TestZeus, which builds AI agents that automate Salesforce testing, went live in 3 days with 1 engineer, and its GTM team then configured 15 trials with no engineering involvement. As Shreyans at TestZeus put it: "You are necessary to run a usage-based system. In the AI era, somebody has to calculate. Flexprice does the job. Use it."

Related terms

Feature gating sits next to the metering and pricing primitives it reads from.

• Spending Cap is the ceiling on consumption, and what the system does when a customer reaches it.

• Usage Metering is the measurement layer a quantity-bound gate depends on.

• Real-Time Metering is what keeps an allowance-backed gate from answering out of date.

• Usage Event is the record produced each time a customer uses a gated capability.

• API Monetization is where gating and metering meet at the endpoint level.

• Credit Burn Down is the pattern for gating on a prepaid balance rather than a plan tier.

FAQ

What is the difference between feature gating and feature flags?

A feature flag controls whether code is live, and a feature gate controls whether a customer has bought access to it. Flags are temporary: you ship one to decouple deploy from release, then delete it. Gates stay as long as the plan stays in the price list.

Is RBAC the same as feature gating?

No. RBAC decides what a user can do inside an account based on their role, such as admin or viewer. Feature gating decides what the account itself has bought. An admin on a free plan and a viewer on an enterprise plan hit different gates.

Where should the access check run?

Run it on the server, at the endpoint that does the work. Client-side gating changes what the interface shows and leaves the API reachable, so anyone reading the network tab can call the paid path directly.

Do customers get access immediately after they upgrade?

They do when the gate resolves entitlements at request time rather than from a cached plan ID. Caching plan data for hours is what produces the upgrade complaint: the customer pays and the locked button stays locked. If you cache, invalidate it on subscription change.