Source: https://www.revvly.ai/blog/feature-gating-in-saas Pricing 9 min read Jul 29, 2026 # Feature gating in SaaS: what to gate, meter, or leave free A product manager decides an advanced export feature should be Pro-only. Three months later, that decision is a backlog ticket competing with real product work. SA Samuel Adeyemo Revenue Systems, Revvly A product manager decides an advanced export feature should be Pro-only. An engineer writes the check: `if (plan === 'pro')`. Three months later, the team wants to move that same feature into a new mid-tier plan, meter it by usage instead of gating it outright, and grandfather in a batch of early customers at the old terms. What should have been a packaging decision is now a backlog ticket, and it is competing with actual product work for sprint time. That gap between the pricing decision and how it is enforced in the product is what feature gating is really about. Most teams treat it as a technical detail. It is a commercial one, and getting it wrong costs revenue in both directions: gate too much and you choke off the product-led growth loop before it starts, gate too little and premium features stop being a reason to upgrade. ## 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. It is different from a feature flag, which controls whether a feature is ready to ship, and different from role-based access control, which governs internal permissions rather than billing. The real work in feature gating is not the on/off switch itself. It is deciding which features to gate at all, and building that logic so a pricing change does not require an engineering ticket every time. ## What feature gating actually is, and what it isn't Feature gating restricts access to a feature or capability based on what a customer has paid for. The question it answers is commercial: has this customer's plan paid for this? That is a different question from the ones two adjacent concepts answer, and conflating them is a common source of confusion. A feature flag controls whether a feature is ready for release, not whether a customer has paid for it. Teams roll a new dashboard out to 10 percent of users to test it before a full launch; that is a flag, not a gate. Role-based access control governs who can do what inside an organization, admins can see billing settings and regular users cannot, which is an organizational permission, not a monetization decision.[1] A useful way to hold the distinction: feature flags test readiness, feature gating enforces payment, and RBAC enforces role. The practical implication is that a gate needs to know more than "on or off." A well-built gate is measured rather than binary: it reflects a customer's active plan, any add-ons that raise a limit, a live trial, and occasionally a promotional override, with the most generous applicable value winning when sources conflict.[1] A homegrown gate built from a single boolean column tends to work fine until the pricing model has more than one moving part, which for most growth-stage SaaS companies happens faster than expected. ## The real decision: what to gate, meter, or leave free Before any of the enforcement mechanics matter, someone has to decide which features belong behind a gate at all. That decision gets made informally more often than it gets made deliberately, and the two failure modes run in opposite directions. ### Over-gating: taking away the reason to say yes The more common mistake in growth-stage SaaS is gating too aggressively. Kyle Poyar, the SaaS pricing analyst behind the Growth Unhinged newsletter, has argued bluntly that most companies' feature gating has gone too far, and that gating the features which actually make free or entry-tier customers successful undercuts both product-led growth and usage-based pricing before either has a chance to work.[2] If a prospective customer cannot get real value out of your entry-level plan, there is no free or low-cost product experience left to convert them, only a paywall with a demo behind it. The features worth protecting are the ones that expand as a customer's usage or team size grows, not the ones a new user needs on day one to decide whether your product solves their problem. Gating the wrong kind of feature does not just cap revenue, it removes the product experience that was supposed to do the selling. ### Under-gating: giving away the upgrade trigger The opposite failure is just as real, if less discussed: leaving genuinely premium, high-cost, or high-value capabilities open to every plan removes the reason anyone upgrades at all. A feature that materially increases a customer's usage of an expensive resource, or that only a subset of buyers with a real budget will value, is a reasonable candidate for a plan boundary. The test is not "could we charge for this," it is whether gating it interferes with a customer discovering the product's core value in the first place. ### Hard gates versus soft gates Feature access does not have to be all or nothing. A hard gate blocks access outright until a customer upgrades. A soft gate, more common in freemium models, allows access up to a usage ceiling or a limited version of a feature, with an upgrade path once the customer hits the limit. Subscription analytics firm RevenueCat's research into consumer app paywalls (a different buyer context than B2B SaaS, but a useful reference point for the underlying mechanics) cites subscription benchmark research showing hard paywalls can convert at meaningfully higher rates than soft ones, while also documenting cases where the opposite held depending on the product and the audience.[3] The lesson that transfers cleanly to B2B packaging is not "hard gates always win," it is that the choice needs to be tested deliberately rather than defaulted to whichever is easier to build. ## Why gating breaks when it lives in application code Most teams start with feature gating built from a handful of database columns and if-else statements scattered through the codebase. It works, until it doesn't. The break point is predictable: a new plan launches, a customer needs a one-off exception, an acquisition brings in a different pricing model, or a plan gets grandfathered for a batch of early customers, and now the gating logic has to be found and updated in every place it was hardcoded. This is a specific instance of a broader problem: pricing and packaging decisions that are supposed to be commercial calls end up gated behind an engineering queue, the same static-pricing trap covered in [how usage-based pricing avoids that trap](https://www.revvly.ai/blog/usage-based-pricing) and in [what actually belongs in each plan](https://www.revvly.ai/blog/saas-pricing-and-packaging-what-goes-in-each-plan). When gating logic is separated from billing entirely, what would otherwise be a multi-sprint change becomes a [pricing experiment](https://www.revvly.ai/blog/pricing-experiment) you can run in days. When it isn't, every packaging idea gets measured against how much engineering time it will cost to test, which quietly narrows the packaging decisions a team is willing to make at all. ## Signs your feature gating is already costing you A few patterns show up reliably before anyone runs a formal audit: - A product or growth idea gets shelved not because it's a bad idea, but because "we'd need engineering to change the gating logic" kills it in the planning meeting. - Nobody can say, without asking an engineer, which specific database flag or code path currently controls access to a given feature. - Support tickets about "why can't I access X" trace back to a plan exception that was hand-coded once and never documented. - A pricing change ships, and the team has no fast way to see whether it moved expansion revenue, churn, or neither, until the next month's dashboard. - Grandfathering a legacy plan means duplicating gating logic rather than configuring an exception. ## Where a modular pricing system closes the gap Most of the problems above trace back to the same root cause: the plan structure, usage limits, and bundle definitions that a gate is supposed to check against live scattered across application code instead of in one system built to hold them. Revvly's modular pricing engine keeps that structure, which plans exist, what's bundled into each, usage-based limits, and regional or currency variations, as configuration rather than code, so a packaging change is a change to the pricing model, not a sprint of engineering work. That does not replace the product team's job of deciding what to gate; it removes the cost of changing that decision once it's made. The other half of the problem is visibility into whether a gating decision is working. Real-time MRR, ARR, and NRR dashboards mean a packaging change shows up in expansion and contraction revenue immediately rather than at the next finance close, and AI-powered churn prediction can flag when a newly aggressive gate is correlating with churn risk before it shows up as a trend in a monthly report. Automated retention workflows can then act on that signal directly, rather than waiting for a customer success manager to notice the pattern manually. None of this replaces the judgment call of which features are worth protecting behind a plan boundary. What it removes is the lag between making that call and seeing whether it was the right one. ## A short framework for auditing your current gates Before changing anything, it's worth answering five questions about the gates you already have: 1. **Can you list every gated feature and the plan boundary it sits behind without asking an engineer?** If not, the gating logic is probably undocumented and scattered. 2. **Does your entry-level plan let a genuinely qualified prospect experience your core value?** If the free or lowest-cost tier can't demonstrate the product's value, it isn't doing its job as a funnel. 3. **Are your most-gated features the ones that scale with customer growth, or the ones a new user needs on day one?** Gating the wrong set quietly caps both activation and expansion. 4. **Can a packaging change ship without an engineering ticket?** If every gating change requires a deploy, pricing experiments will be rare by default, not by design. 5. **Would you know within days, not a month, whether a gating change affected churn or expansion revenue?** If the answer is you'd find out at the next close, the feedback loop is too slow to iterate on. ## Frequently asked questions **What is feature gating in SaaS?** Feature gating is the practice of restricting access to specific product features, usage limits, or capabilities based on a customer's subscription plan. It's a commercial mechanism, not a technical one: it answers whether a customer has paid for a given feature, not whether that feature is ready to release. **What is the difference between feature gating and feature flags?** A feature flag controls whether a feature is ready to ship and is typically used to roll out functionality to a subset of users before a full release. Feature gating controls whether a paying customer's plan entitles them to a feature. Flags test readiness; gates enforce payment.[1] **What is the difference between feature gating and role-based access control (RBAC)?** RBAC governs what a user can do based on their role inside an organization, for example, only admins can see billing settings. Feature gating governs what a customer's plan entitles them to access across the whole product, regardless of their role within their own company.[1] **Should I gate a feature or meter it by usage?** Gate features where access itself is the value differentiator between plans. Meter features where the cost or value scales with how much a customer uses it, so usage-based billing captures growing value instead of a flat plan boundary either blocking or fully allowing it. **What features should never be gated?** Features a new or entry-tier customer needs to experience your product's core value are poor gating candidates. Gating them removes the free or low-cost product experience that's supposed to demonstrate value before someone commits to paying. **Can a hard paywall work for a B2B SaaS product?** It can, but the trade-off is different than in consumer apps. A hard gate filters for buyers who already understand their problem well enough to commit before trying the product, which works when your sales motion supports pre-qualifying leads. It works less well when your growth strategy depends on prospects discovering value through hands-on product use first.[3] **How long does it take to change feature gating once it's built into application code?** It depends entirely on how the original gating logic was implemented. If access checks are hardcoded per feature across the codebase, even a simple packaging change (moving a feature to a different tier, adding a usage limit) typically requires a scoped engineering task and a deploy. If the plan structure and limits are held in a configuration layer instead, the same change is a configuration update. ## Sources 1. Stigg, "Feature Gating & 8 Ways to Implement It," by Sara Nelissen, updated March 11, 2026. [https://www.stigg.io/blog-posts/feature-gating](https://www.stigg.io/blog-posts/feature-gating) 2. Kyle Poyar, Growth Unhinged, "Why you should give away your features." [https://kylepoyar.substack.com/p/why-you-should-give-away-your-features](https://kylepoyar.substack.com/p/why-you-should-give-away-your-features) 3. RevenueCat, "Hard paywall vs soft paywall: How much of your app should be locked?," by Peter Meinertzhagen. [https://www.revenuecat.com/blog/growth/hard-paywall-vs-soft-paywall/](https://www.revenuecat.com/blog/growth/hard-paywall-vs-soft-paywall/) ## Frequently asked questions ### What is feature gating in SaaS? Feature gating is the practice of restricting access to specific product features, usage limits, or capabilities based on a customer's subscription plan. It's a commercial mechanism, not a technical one: it answers whether a customer has paid for a given feature, not whether that feature is ready to release. ### What is the difference between feature gating and feature flags? A feature flag controls whether a feature is ready to ship and is typically used to roll out functionality to a subset of users before a full release. Feature gating controls whether a paying customer's plan entitles them to a feature. Flags test readiness; gates enforce payment. ### What is the difference between feature gating and role-based access control (RBAC)? RBAC governs what a user can do based on their role inside an organization, for example, only admins can see billing settings. Feature gating governs what a customer's plan entitles them to access across the whole product, regardless of their role within their own company. ### Should I gate a feature or meter it by usage? Gate features where access itself is the value differentiator between plans. Meter features where the cost or value scales with how much a customer uses it, so usage-based billing captures growing value instead of a flat plan boundary either blocking or fully allowing it. ### What features should never be gated? Features a new or entry-tier customer needs to experience your product's core value are poor gating candidates. Gating them removes the free or low-cost product experience that's supposed to demonstrate value before someone commits to paying. ### Can a hard paywall work for a B2B SaaS product? It can, but the trade-off differs from consumer apps. A hard gate filters for buyers who already understand their problem well enough to commit before trying the product, which works when a sales motion supports pre-qualifying leads, and works less well when growth depends on prospects discovering value through hands-on use first. ### How long does it take to change feature gating once it's built into application code? It depends entirely on how the original gating logic was implemented. If access checks are hardcoded per feature across the codebase, even a simple packaging change typically requires a scoped engineering task and a deploy. If the plan structure and limits are held in a configuration layer instead, the same change is a configuration update. 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.