Source: https://www.revvly.ai/blog/feature-gating-for-saas-pricing-tiers

Pricing

9 min read

Jul 27, 2026

# Feature gating: how to decide which features belong in which plan

The pricing team designed a tier in an afternoon. The engineering team spent three sprints excavating a decision buried in a dozen scattered conditionals.

SA

Samuel Adeyemo

Revenue Systems, Revvly

A product lead wants to launch a new tier. Three features need to move behind it: an advanced report, a higher API limit, and a new export format. The pricing decision itself takes an afternoon. Shipping it takes three sprints, because the checks that control who can see what are scattered across a dozen files as `if user.plan == "pro"` conditionals that nobody fully maps anymore. The pricing team designed a tier. The engineering team has to excavate a decision.

This is the practical problem behind feature gating: not whether to restrict features by plan (almost everyone already does), but how to do it so a pricing change is a configuration update instead of an engineering project.

## Quick answer

> Feature gating is the practice of controlling which product features, usage limits, or capabilities a customer can access based on their subscription plan, add-ons, or trial status. It is a commercial mechanism, not a technical one: the question a gate answers is "has this customer paid for this," not "is this feature ready to ship." Done well, gates read from a single entitlement record tied to billing, so a plan or pricing change updates access without a code deploy.

## What feature gating is, and why it gets confused with feature flags

Feature gating and feature flags look similar in code (both involve conditionally showing or hiding something) but they solve different problems. A feature flag controls whether a feature is *ready*: it lets a team roll a new dashboard out to 10% of users before a full release, and it usually gets deleted once the rollout finishes. A feature gate controls whether a customer has *paid* for something, and it needs to persist for the life of the subscription.

Stigg's guide to feature gating draws this distinction clearly: feature flags serve a technical purpose, feature gating serves a commercial one, and conflating the two is one of the more common reasons homegrown gating systems become hard to maintain.[1] Teams that build gating on top of their feature-flag tooling often find the two purposes fight each other: a flag framework optimized for quick technical rollouts isn't built to track usage limits, add-ons, or what happens when a customer's plan changes mid-cycle.

The underlying data model beneath a gate is usually called an entitlement: a record of what a specific customer is allowed to access right now, based on their active plan, any add-ons, trial status, and promotional overrides. When those sources conflict, the most generous one typically wins.[1] Entitlements are what make gating measured rather than a simple yes/no switch.

## The four types of gates

Not every gate works the same way, and picking the wrong type for a given feature is a common source of both lost revenue and customer frustration.

### Hard gates

A hard gate is all-or-nothing: the feature is either fully available or fully hidden, based on plan. Best used for genuinely premium capabilities that a lower tier was never meant to include, like advanced reporting or SSO.

### Usage-limit gates

A usage-limit gate caps a quantity rather than blocking a feature outright: a set number of seats, projects, or API calls per plan. These work well when the feature itself should be available to everyone, but the *volume* of use is the thing worth charging for.

### Metered or overage gates

A metered gate allows usage past a included limit, but bills for the overage instead of blocking access outright. This is the mechanism behind usage-based add-ons and consumption pricing, and it requires the gate and the billing system to agree on the same usage numbers in real time, not just at the end of the billing cycle.

### Soft or upsell gates

A soft gate shows a customer what they're missing rather than hiding it. Orb's primer on feature gating frames this as one of the core reasons to gate in the first place: when a customer can see a locked feature that matches something they already need, it creates a natural reason to upgrade, rather than a customer discovering the feature exists only after they've already left for a competitor.[2]

## A framework for deciding what to gate

The instinct is to gate whatever feels most advanced. A better filter is willingness to pay: a feature belongs behind a gate if a meaningful share of customers would pay specifically for it, not just because it took the most engineering effort to build.

A few principles hold up across most SaaS pricing models:

- **Never gate the core value proposition.** If a plan can't demonstrate why your product is worth using at all, it won't convert, no matter how generous the upgrade path looks later.
- **Gate at the action, not the view.** Stigg points to Canva's checkout flow as an example: free users can view and edit premium templates, but the gate triggers at export, not at browse.[1] Letting a customer experience the value before the gate creates a far stronger upgrade motivation than blocking access on sight, and it also simplifies the underlying logic, since there's one enforcement point instead of many.
- **Show the upgrade path in context.** When a gate fires, the resulting prompt should reference the specific feature the customer just tried to use, not a generic "upgrade now" message pointing at a full plan comparison table.
- **Keep at least one anchor feature in every paid tier.** Every tier needs a reason to exist on its own, not just as a stepping stone to the next one up.

## Why hardcoded gates become a technical debt problem

The trap almost every team falls into is the same one in the opening example: gating logic written directly into application code, as scattered conditional checks tied to a plan name or user attribute. It works fine for the first two or three tiers. It stops working the moment pricing needs to move faster than the codebase can be safely changed, which for most growing SaaS companies is sooner than expected: three-in-four software companies changed either pricing or packaging in the past year, according to a 2026 survey of more than 230 B2B software and AI companies by Kyle Poyar's Growth Unhinged, and it's now the largest, most established companies making the most changes, not just early-stage startups experimenting with their first pricing page.[3]

Every one of those changes, if gating lives in scattered code, means finding every place a plan is checked, confirming none of them were missed, and shipping a deploy to change what is fundamentally a business decision. Stigg frames the signal to watch for directly: gating is working when pricing changes ship through configuration instead of code, and it's failing when engineering time keeps getting absorbed by access logic instead of product work.[1] The second failure mode compounds. Nobody on the team can say with confidence which features are gated where, add-ons and grandfathered exceptions pile up as special cases, and every new plan or [bundle](https://www.revvly.ai/blog/saas-pricing-and-packaging-what-goes-in-each-plan) multiplies the number of checks that have to be found and updated correctly.

## Changing gates without breaking existing customers

Pricing changes are inevitable. The question is whether an existing customer's access breaks the day a gate changes underneath them.

The safer pattern separates the entitlement record from both the billing system and the application code, so a plan change is a data update rather than a code change. That structure makes three things possible that hardcoded checks generally don't:

1. **Grandfathering.** Existing customers keep the access tied to the plan they originally purchased, while new signups see the updated tiers, without maintaining two parallel code paths.
2. **Migration windows.** Customers on a deprecated plan can be moved to a new one with advance notice and a defined cutover date, rather than an access change that happens without warning.
3. **Mid-cycle plan changes without manual cleanup.** When a customer upgrades, downgrades, or adds a module mid-cycle, the entitlement updates immediately and proration handles the billing difference, instead of a support ticket and a manual database edit.

This is also where [usage-based pricing](https://www.revvly.ai/blog/usage-based-pricing) and modular pricing intersect with gating directly: a modular pricing engine that treats plans, add-ons, and usage-based components as data rather than code is what makes it possible to launch a new tier, adjust a usage limit, or run a [pricing experiment](https://www.revvly.ai/blog/pricing-experiment) without a corresponding engineering project each time. Revvly's pricing engine works this way for exactly this reason: modules, tiers, usage-based and bundle pricing, and proration for mid-cycle changes are configured rather than hardcoded, which is a different job from feature gating itself but relies on the same underlying idea, that pricing logic should live in a system of record, not scattered through application code.

## How SaaS teams typically approach feature gating

There isn't one right answer, and the choice usually comes down to how much pricing complexity a team expects to manage over the next year or two, not just today.

- **Custom, in-house checks.** The default starting point for most teams, and often the right one when there are only one or two tiers and pricing rarely changes. The risk is exactly the technical debt problem above, and it tends to surface earlier than teams expect.
- **Dedicated entitlements or feature-gating tools.** Point solutions built specifically to manage the entitlement layer, separate from billing. These typically sit alongside an existing billing system rather than replacing it.
- **Gating built into a broader subscription and revenue platform.** Some teams prefer feature gating to live in the same system that already handles billing, pricing rules, and revenue reporting, rather than adding another integration point. This is the category a platform like Revvly falls into, alongside other subscription and revenue platforms that bundle entitlements with billing and analytics.

None of these is universally correct. A five-person startup with one pricing page has different requirements than a company running usage-based add-ons across five regions.

## A short checklist before you gate a feature

- Would a meaningful share of customers pay specifically for this, separate from the rest of the plan?
- Can the gate trigger at the point of use rather than blocking visibility outright?
- Does the upgrade prompt reference the specific feature the customer tried to access?
- If this gate needs to change in six months, does that require a deploy, or a configuration update?
- Is there a plan for what happens to existing customers if this gate's rules change?

## Pricing that lives in code instead of a system of record

The deeper issue behind most feature-gating headaches isn't the gating logic itself, it's that pricing decisions and application code end up living in different places, owned by different teams, with no shared source of truth. A product lead changes a tier structure in a slide deck. An engineer implements it as a conditional. Six months later, nobody can say for certain which version is actually live. That's the same fragmented-stack problem that shows up in billing, reporting, and renewal tracking when pricing logic isn't centralized, and it's worth solving at the system level rather than one gate at a time.

## Frequently asked questions

**What is feature gating?** Feature gating is the practice of controlling access to specific features, usage limits, or capabilities based on a customer's subscription plan, add-ons, or trial status. It is focused on monetization, deciding what a customer has paid to access, rather than on technical rollout or testing.

**What is the difference between feature gating and feature flags?** Feature flags control whether a feature is ready to release, typically to a small group of users during a rollout, and are usually removed once the release is complete. Feature gating controls whether a paying customer can access a feature, persists for the life of the subscription, and updates automatically when a plan changes.[1]

**Which features should be gated?** Features that a meaningful share of customers would pay for specifically, not simply the features that took the most engineering effort. Core functionality that demonstrates the product's basic value should generally stay ungated, since a plan that can't prove its worth won't convert customers to begin with.

**What is a soft gate versus a hard gate?** A hard gate fully blocks access to a feature outside a given plan. A soft gate shows the feature as visible but locked, which lets a customer see what they'd get by upgrading rather than discovering the feature only if they leave for a competitor.[2]

**Can gating logic live inside a billing system?** It can, but many billing systems weren't built to also manage plan-level access decisions, usage limits, and grandfathering rules. Some teams keep gating logic in the billing system directly; others use a separate entitlement layer or a broader subscription platform that manages billing, pricing rules, and access together.

**How do you change a gate without breaking existing customers?** By keeping the entitlement record, what a specific customer is allowed to access, separate from both the application code and the billing system, so a plan change updates a data record rather than requiring a deploy. This is what makes grandfathering and migration windows possible without maintaining parallel code paths.

**How often do SaaS companies actually change pricing or packaging?** More often than most teams plan for. A 2026 survey of over 230 B2B software and AI companies found that three-in-four had changed pricing or packaging within the past year, with the largest companies making the most changes.[3]

## Sources

1. Sara Nelissen, "Feature Gating & 8 Ways to Implement It," Stigg, updated March 11, 2026. [https://www.stigg.io/blog-posts/feature-gating](https://www.stigg.io/blog-posts/feature-gating)
2. Calista Reyes, "What is feature gating? + Reasons to use it or avoid it," Orb, 2025. [https://www.withorb.com/blog/feature-gating](https://www.withorb.com/blog/feature-gating)
3. Kyle Poyar, "The state of B2B monetization in 2026," Growth Unhinged, May 13, 2026. [https://www.growthunhinged.com/p/the-state-of-b2b-monetization-in-2026](https://www.growthunhinged.com/p/the-state-of-b2b-monetization-in-2026)

*Note: Stigg and Orb are entitlements and billing infrastructure vendors, cited above only for their educational framework and definitions of feature gating, not as a comparison to Revvly.*

## Frequently asked questions

### What is feature gating?

Feature gating is the practice of controlling access to specific features, usage limits, or capabilities based on a customer's subscription plan, add-ons, or trial status. It is focused on monetization, deciding what a customer has paid to access, rather than on technical rollout or testing.

### What is the difference between feature gating and feature flags?

Feature flags control whether a feature is ready to release, typically to a small group of users during a rollout, and are usually removed once the release is complete. Feature gating controls whether a paying customer can access a feature, persists for the life of the subscription, and updates automatically when a plan changes.

### Which features should be gated?

Features that a meaningful share of customers would pay for specifically, not simply the features that took the most engineering effort. Core functionality that demonstrates the product's basic value should generally stay ungated.

### What is a soft gate versus a hard gate?

A hard gate fully blocks access to a feature outside a given plan. A soft gate shows the feature as visible but locked, letting a customer see what they'd get by upgrading rather than discovering the feature only after leaving for a competitor.

### How do you change a gate without breaking existing customers?

By keeping the entitlement record, what a specific customer is allowed to access, separate from both the application code and the billing system, so a plan change updates a data record rather than requiring a deploy. This is what makes grandfathering and migration windows possible.

### How often do SaaS companies actually change pricing or packaging?

A 2026 survey of over 230 B2B software and AI companies by Growth Unhinged found that three-in-four had changed pricing or packaging within the past year, with the largest companies making the most changes.

SA

Samuel Adeyemo

Revenue Systems, Revvly

Samuel builds the systems that turn billing events into trustworthy revenue numbers. He writes about retention, pricing, and the operational details that decide whether the metrics hold up.

Revvly

Orchestrate the flow of revenue.

© 2026 AcceleratorApp Limited. All rights reserved.