Expansion Revenue From Feature Gating vs Usage Gating in SaaS

Feature gating and usage gating get treated as interchangeable levers in most pricing conversations, but that is the first mistake worth correcting. They intercept expansion revenue at different moments in a customer's journey, and treating them as substitutes produces pricing structures that miss the revenue they were built to capture. Feature gating controls which capabilities a customer can reach, tiered by subscription level, and the signal it reads is capability desire: a customer who wants to do something new that the current plan does not allow. Capability desire and volume growth do not move together in any reliable way. A customer can expand usage heavily and never want a new feature, and a customer can need advanced capability while using only modest volume. So if you gate only on features, you miss the revenue sitting in your volume-driven accounts, and if you gate only on usage, you miss the revenue sitting in your capability-driven ones.

How feature gating generates expansion revenue

Feature gating works best when a product has capability tiers that map cleanly onto distinct buyer personas or distinct stages of organizational maturity. The mechanism locks outcomes, not raw tools, behind higher tiers, so customers run into something they already recognize as valuable and choose to upgrade on their own. Slack's structure shows the logic clearly: messaging and file sharing sit in the free tier because they deliver the core individual workflow, while full unlimited message history, SSO, and compliance exports sit behind paid tiers because those are organizational-value features that security and compliance buyers fund. HubSpot's CRM runs on the same principle. Feature gating also lowers the cost of landing a customer in the first place, because a free tier that delivers real value without a credit card reduces adoption friction while the gate still stays in place as the moment where growth turns commercial.

The ceiling shows up once a customer reaches the tier that matches its needs. At that point there's no higher gate left that the customer wants, and the vendor has no mechanism to capture additional revenue from a customer that is simply consuming more of what it already pays for. Either way, feature gating stalls out right where a customer's growth turns volume-driven instead of capability-driven, and that is the gap usage gating was built to fill.

Usage gating generates expansion revenue and fits AI-era products

Usage gating captures expansion automatically as a customer's business grows, with no sales cycle, no upgrade negotiation, and no new capability the customer has to be convinced it needs. Limits tied to a natural success metric, whether that's API calls, contacts managed, storage consumed, or tokens processed, mean that a customer who hits a cap has already proven value realization by using the product enough to exhaust the allotment. GitHub's structure illustrates the split: unlimited repositories sit in the free tier because that's the core developer workflow, while CI/CD minutes are capped because pipeline compute is where usage scales with organizational activity. HubSpot applies the same structure to marketing contacts and marketing email sends, where the limit grows in step with the customer's own customer base, so billing tracks business expansion directly.

For AI products, usage gating is close to the only model that holds up at scale, not one option among several. The inference cost asymmetry makes the case even sharper. A metering and billing platform built for consumption-based pricing, like Flexprice, can track those usage events as they happen and tie them straight to expansion revenue, with no manual work and no wait for a renewal cycle to catch up. Usage-based models also give investors and finance teams a cleaner read on product-market fit: expansion MRR as a share of total MRR is one indicator of a usage-based business compounding revenue from existing customers without a matching rise in sales and marketing spend.

What credits solve between the two gating mechanisms

Credits work as a packaging layer, not a third gating category, because they translate raw usage dimensions into units a buyer can actually reason about. That translation matters because a buyer facing a bill denominated in tokens or GPU-seconds has no intuition for what a fair price looks like, while a buyer facing a block of credits at a known price does. Credits solve three problems at once: they smooth inference cost variance by letting a customer buy a block at a fixed price instead of a bill shaped by per-token complexity, they create advance revenue recognition through upfront purchases, and they generate a natural upsell moment, since a customer who exhausts a credit block is by definition ready to expand.

The Salesforce Agentforce trajectory shows how much complexity credits eventually have to resolve. Once that metric becomes clear, you should anchor the credit abstraction to it explicitly or replace it outright with direct usage pricing, because a credit system left in place past that point hides the very cost variance it was built to smooth.

Designing a hybrid of both gating mechanisms

The highest-performing pricing structures run feature gating and usage gating at the same time, one capturing capability-driven expansion and the other capturing volume-driven expansion. Picking a mechanism matters less than deciding where the line between them falls. The boundary principle is straightforward: gate on features where different customer personas have genuinely different capability needs, and gate on usage where the same capability delivers more value as volume rises. SSO, audit logs, and compliance exports belong behind a feature gate because they serve organizational buyers specifically, and no amount of usage turns a small team into a buyer who wants them. API calls, storage, contacts managed, and compute minutes belong behind a usage gate because every tier of buyer uses these capabilities already, and what varies between them is volume.

A practical test before shipping any gate is to ask whether the expansion signal it creates comes from a customer wanting something new or from a customer doing more of something it already does. The distinction between capability desire and volume growth carries a direct infrastructure implication here: a product running both gates needs a billing engine that can model multiple pricing dimensions at once, layering fixed subscription tiers with metered usage charges so that a single customer record reflects both the plan a customer subscribes to and the volume it consumes. Timing discipline matters just as much on the usage side. Caps should engage only after a customer has experienced the product's core value, because charging before that point produces churn.

Outcome-based pricing as the next evolution beyond usage gating for AI products

Usage gating solves the mismatch feature gating leaves behind, but for AI products, the customer's actual value is a business outcome, not a unit of computation, so billing on tokens or API calls still leaves a gap between what the customer values and what it gets charged for. Outcome-based pricing closes that remaining gap by billing the result.

Intercom's Fin product is the most documented live example of this shift. Fin charges roughly $0.99 per resolved conversation. It bills when the customer confirms the AI solved the problem, or when the customer simply exits without asking for further help, which counts as an assumed resolution. On that model, Intercom scaled Fin from $1M to more than $100M in ARR, revenue that neither a feature gate nor a raw usage gate on API calls would have captured. HubSpot's Breeze Customer Agent and Prospecting Agent moved to the same logic: they charge $0.50 per resolved conversation and $1 per lead, a direct translation of business result into a billing unit. Salesforce's Agentforce shift to pay-per-resolution at a flat $2.00, regardless of how many actions the agent takes to reach that resolution, follows the identical principle: the customer pays for the outcome, not the computational path that produced it. Outcome-based pricing needs billing infrastructure that can attach arbitrary outcome metrics to an invoice, not just count tokens, but most usage billing platforms were built for raw consumption and were never designed to do that.

What the billing infrastructure must do

The gating strategy a product team chooses determines the billing infrastructure it needs, and most AI product billing failures trace back to the gap between what subscription-era billing platforms can do and what usage-gated or outcome-gated products require. Feature gating needs entitlement management: a system that checks plan membership at the moment of access and enforces tier boundaries without engineering having to intervene every time a plan changes. Usage gating needs real-time metering, where events get ingested, rated, and compared against customer entitlements at the speed consumption actually happens, which for AI inference means millisecond-level processing.

The practical architecture behind that metering runs through five stages: ingestion, normalization, enrichment, rating, and settlement. Hybrid gating runs feature and usage gates together, so both systems need to operate on the same engine at once. Running them as two separate billing codepaths reconciled monthly is the failure mode most teams hit before they go looking for purpose-built infrastructure. Credit wallets add a third dimension on top of that, since prepaid balances have to sit alongside postpaid invoicing on the same engine, with spend visibility surfaced to the customer in real time. If a customer can't see credit consumption until an invoice arrives, you get bill shock, churn, and support costs that outweigh whatever the billing platform itself costs.

Build vs. buy for metered billing infrastructure when gating strategy adds complexity

A flat subscription product can run on standard billing tooling at low engineering cost, but once you add usage metering, that calculus changes a lot. If a product is usage-gated, accurate metering, billing, and reconciliation cost you an order of magnitude more in engineering than a flat subscription setup needs. The build path also carries costs that extend well past initial development: whichever team builds the metering system owns it indefinitely, and upgrades, edge cases, compliance changes, and debugging all accrue as permanent maintenance.

Teams that chose to buy instead of build show you what that avoided cost looks like. Knock saved six months of engineering time. Each of them avoided the build path because usage metering at the scale their products required was never going to be a one-time project. Some teams split the problem instead of choosing one side outright: owning the event pipeline, because they already run Kafka and ClickHouse infrastructure for analytics and anomaly detection, while buying the billing layer itself, so that the billing platform handles pricing logic, invoice generation, credit wallets, and revenue recognition while the metering layer handles ingestion and aggregation. One evaluation criterion for bought infrastructure gets overlooked more than it should: portability, the ability to export raw events in full, on demand. Vendor acquisition risk is a real operational concern, and a team that cannot retrieve its own metering data from a billing vendor is dependent on that vendor's continued independence in a way few teams would choose deliberately.

Flexprice fits the shape of this problem directly: a single system that ingests usage events at millisecond speeds, models any combination of pricing dimensions including tokens, GPU-minutes, API calls, and outcome metrics, supports prepaid credit wallets and postpaid invoicing on the same engine, and can be deployed on-premises for enterprise buyers who require it. You build it for teams that have hit the point where subscription billing tools stop counting accurately and usage-gated products start failing under the load.

Choosing between feature gating, usage gating, and a hybrid

The choice between gating mechanisms is an empirical question about where a product's value scales, and the answer comes from usage telemetry. Three diagnostic questions settle it in most cases. Does customer lifetime value correlate more strongly with the number of distinct capabilities a customer uses, or with the volume of a single capability it consumes? Strong correlation with capability breadth points toward feature gating, while strong correlation with consumption volume points toward usage gating. Are the highest-value customers distinguishable from lower-value ones by what they can do, or by how much they do? Feature gating captures the expansion in the first case, usage gating in the second. Do power users hit a limit and want more of the same, or do they hit a limit and want something new? If it's the former, a usage gate is underpriced or set too tight; if it's the latter, a feature tier is missing.

Products where per-seat pricing is already breaking down, AI agents doing work without human sessions attached, inference costs varying by orders of magnitude across customers, should weight usage gating heavily from the outset, because feature gating alone cannot capture the revenue that computational scale generates. Feature gating works because it creates a visible upgrade moment: a customer recognizes a capability as valuable and upgrades without a sales push behind it. But once that customer reaches the tier that meets its needs, feature gating has no further lever to pull, so many SaaS products layer usage limits on top of their tier structure, and then they need billing infrastructure that can reconcile both signals onto a single invoice. You should treat pricing as a continuous lever, not a decision you make once at launch. Teams that get this right instrument their telemetry from day one, review usage patterns every quarter, and adjust caps and gates without requiring an engineering sprint each time they do. You can adjust gates without code changes, which turns pricing into a genuine growth mechanism.