See how dynamic paywalls handle feature gates, trials, credit balances, and dynamic metered paywalls without hardcoded plan logic.
A trial user finds the AI agent's batch mode and queues 800 runs over a weekend. The paywall checked permissions on session start, every job cleared, and by the time the overage shows up in billing, the user has churned, and the engineering team is patching the check in the codebase.
Static paywalls run once and trust the result. But dynamic paywalls enforce continuously, against the live usage state, before each relevant action.
A dynamic paywall enforces limits continuously against live usage state rather than checking permissions once and trusting the result for the session. The check runs before each relevant action, reads current consumption data, and resolves a decision in the request path before the action completes.
Session-level permission checks work fine for flat subscriptions and fixed seat counts, but they break when usage is variable, and cost per action can be high.
A user who burns through 90% of their monthly token allocation by Tuesday afternoon should have a different experience than a user who has barely started. A session-level check has no way to produce that behavior because it stopped reading state hours ago.
Dynamic paywalls are not all the same. The UI might look like a modal, a disabled button, a usage banner, or a hard block, but the real difference is underneath, in what triggered the paywall, what the system is enforcing, and what the product offers the user next.
For engineering teams, the paywall component is the visible part. The critical path is the runtime decision behind it:
That last question is where most paywall implementations either hold up or start leaking logic back into application code.
Usage-triggered paywalls fire when a customer approaches or reaches a plan limit. The common version is an upgrade prompt at 80% usage, but the threshold should be treated as a configuration rather than product logic.
An 80% warning works well when usage is predictable in terms of API calls, exports, seats, projects, reports, storage, or monthly workflow runs, the kind of usage you'd expect from a traditional SaaS plan. It gets harder once usage swings with AI token consumption or agent activity, which is where thresholds alone start to strain.
The engineering mistake is hardcoding the threshold into the application:
if (usage >= plan.limit * 0.8) {
showUpgradePrompt()
}
That works until Pro needs a 75% warning, Enterprise needs a 90% warning, one customer has a contract override, and a new add-on raises the limit mid-cycle.
A better pattern is to ask the entitlement layer for the current enforcement state:
{
allowed: true,
feature: "api_calls",
limit: 100000,
usage: 81250,
remaining: 18750,
enforcement: "warn",
threshold: 0.8,
paywallVariant: "upgrade_to_scale"
}
The application should not have to know why the warning fired. The application should know what state to render and whether the action can continue.
Once usage thresholds live in configuration, product and growth teams can test 70%, 80%, or 90% prompts without asking engineering to ship another conditional.
Feature-triggered paywalls fire when a customer interacts with a feature outside their commercial allowance.
This is the classic “Free user clicks advanced dashboards” moment. It shows a locked state, explains the higher-tier feature, and points the user toward the right plan.
The backend is where the decision needs discipline.
A feature-triggered paywall should not rely on frontend hiding. Hiding a button helps with product experience, but it does not enforce access. The backend still needs to check the entitlement before the expensive or restricted action runs.
A useful feature entitlement check returns more than true or false:
{
allowed: false,
feature: "advanced_dashboards",
requiredPlan: "pro",
currentPlan: "free",
denialReason: "plan_limit",
upgradePath: "pro",
includedFeatures: [
"custom_export_templates",
"team_sharing",
"api_access"
]
}
That context lets the paywall say something specific.
For AI products specifically, this matters even more. A "premium model access" feature gate needs to reflect the same catalog the credit ledger uses downstream, or the paywall promises something the metering layer can't honor.
That drift is where support tickets, confused customers, and one-off exceptions start.
Trial expiry paywalls fire when temporary access turns into a commercial decision.
For a static implementation, the trial ends, the product shows an upgrade screen, and the backend blocks access. That might be enough for a small product, but it becomes too rigid once trials vary by segment, plan, contract type, sales motion, or product usage.
A dynamic trial expiry paywall treats trial end as a state transition:
trial_active -> grace_period -> read_only -> paid_plan
Each state can have different enforcement rules:
The entitlement layer needs to resolve all of that before the product decides what to show:
{
allowed: false,
trialState: "expired",
enforcement: "grace_period",
gracePeriodEndsAt: "2026-07-03T00:00:00Z",
recommendedPlan: "team",
usedFeatures: [
"ai_workflows",
"api_access",
"shared_projects"
]
}
The product experience can stay conversational, but the enforcement should be exact. Trial logic gets messy when it lives across billing webhooks, CRM fields, support overrides, and application conditionals.
Dynamic trial paywalls work best when trial state, feature usage, plan eligibility, and overrides resolve through one runtime system.
Dynamic metered paywalls are the paywall type most teams underestimate.
A feature-triggered paywall asks, “Can this customer access this feature?”
A dynamic metered paywall asks, “Can this customer perform this specific action, at this specific cost, right now?”
That difference matters for products where each action has a variable cost:
A session-level check is not enough here. At session start, the product does not know how many tokens the user will burn, how many downstream calls an agent will make, or whether 10 concurrent jobs will cross the customer’s limit at the same time.
The check has to happen before the metered action executes. For expensive or multi-step actions, the system may need a reserve, commit, and refund flow.
A common pattern looks like this:
That flow prevents the product from discovering overages after the cost has already been incurred.
A dynamic metered paywall check might return:
{
allowed: false,
feature: "ai_agent_run",
estimatedCost: 2400,
unit: "credits",
availableBalance: 1800,
enforcement: "hard_limit",
depletionBehavior: "block",
upgradePath: "buy_more_credits",
reason: "insufficient_balance"
}
Or, for a soft-limit customer:
{
allowed: true,
feature: "ai_agent_run",
estimatedCost: 2400,
unit: "credits",
availableBalance: 1800,
enforcement: "soft_limit",
overageAllowed: true,
paywallVariant: "usage_warning"
}
This is where metering and entitlements have to work together. Metering tells the system what has been consumed. Entitlements tell the system what the customer is allowed to consume. The paywall sits at the enforcement point between the 2.
The hard parts are the parts engineers care about:
A simple counter works until the product has concurrent usage, variable-cost actions, enterprise overrides, and finance asking why the credit ledger does not match actual consumption.
At that point, dynamic metered paywalls stop being a UI pattern and become infrastructure.
Most teams do not start by building a paywall system. Instead, they use what is already in the stack.
Billing has the plan record, feature flags already control product behavior, and the application already has plan checks somewhere in the codebase.
That starts to run into problems when the paywall has to make a live decision across usage, credits, trials, add-ons, overrides, and plan limits.
Billing systems are good at commercial records. They know what plan a customer is on, what the customer has paid, and what should be invoiced at the end of the cycle.
Dynamic paywalls need a different kind of state. They need to know what the customer is about to do, how much usage remains, and whether the action should be allowed before it runs.
That timing matters.
If a customer starts an export, calls an API, or runs an AI workflow, billing usually sees the usage after the product reports it. That’s too late for enforcement.
You can store access rules in billing metadata, but the application still has to fetch, cache, interpret, and enforce those rules. At that point, billing is only a source of commercial facts. The product still owns the paywall logic.
Feature flags are useful for shipping software safely. They help teams roll out features by user, segment, environment, or experiment group.
Dynamic paywalls need more than that. They need to know whether a customer can use a feature under the current plan, trial, add-on, usage limit, credit balance, or contract override.
That is where flag systems start to bend out of shape.
The flag might know whether a feature is enabled. However, it usually does not know that a customer upgraded 3 minutes ago, moved into a grace period, bought more credits, or has a grandfathered limit.
So teams build sync jobs between billing, flags, webhooks, and the application. That can work for a while, but every new pricing rule adds another moving part.
Feature flags should control rollout. They should not become the source of truth for what a customer paid for.
Hardcoded plan logic is the fastest way to ship the first version.
A few checks like plan === "pro" feel harmless at the start, and the logic is local, readable, and cheap to build.
But then the plan model changes.
Free gets 10 exports. Pro gets 100. Enterprise gets unlimited. One customer gets 500 through a contract. Another customer stays on the old Pro plan. A new add-on raises the limit. A trial includes exports for 14 days.
The application becomes the pricing system without anyone deciding it should.
Plan checks end up in route handlers, frontend components, middleware, background jobs, support scripts, and config files. Every packaging change becomes a code search, and every exception creates another branch.
The hard part is knowing whether a conditional is still the real rule 6 months later.
The question to ask here is “What is this customer allowed to do right now?” That is an entitlement question.
Entitlements define the commercial permissions attached to a customer. They describe which features the customer can access, which limits apply, how much usage remains, and what should happen when the customer gets close to or exceeds a limit.
A dynamic paywall needs that answer before the action completes. Billing, feature flags, and hardcoded plan checks can each cover part of the problem, but none of them were built to resolve the full access decision in the request path.
That is why paywall logic needs its own runtime layer between the product and the commercial systems. The entitlement layer becomes the product enforcement source of truth.
An entitlement is a commercial allowance the product can enforce at runtime.
For dynamic paywalls, that allowance needs a measurable rule the application can check before an action runs.
Examples:
That is the difference between access control and entitlement enforcement. RBAC says whether a user has a role, but entitlements say what the customer has paid for, what has been granted, how much remains, and what should happen when usage approaches the limit.
For engineering teams, the entitlement layer becomes the runtime source of truth for dynamic paywalls.
It sits between the application and the billing system. Billing keeps the commercial record, while the entitlement layer resolves the live product decision.
When the application receives a request, the flow looks like this:
The application should only need to ask one question: Can this customer perform this action right now?
The entitlement layer handles the rest.
A dynamic paywall check can return:
{
"allowed": false,
"feature": "api_calls",
"limit": 10000,
"usage": 10000,
"remaining": 0,
"enforcement": "hard_limit",
"upgradePath": "pro",
"reason": "usage_limit_reached"
}
That response gives the backend a clear enforcement decision and gives the frontend enough context to render the right paywall.
For dynamic metered paywalls, this matters even more. The limit moves with every request, credit debit, token burn, export, compute job, or agent run. The entitlement layer has to read the current balance before the action executes and update usage as consumption accumulates.
The paywall itself is only the visible result, and the entitlement check already made the decision.
That is what makes dynamic paywalls configurable. Engineering teams can change the limit, tier, threshold, enforcement mode, or upgrade path through the entitlement model instead of rewriting product logic. The application keeps calling the same entitlement check.
For a product with 3 plans and a few static limits, an in-house entitlement service can hold for a long time. The pressure shows up when the model adds:
At that point, the entitlement layer becomes infrastructure. It has to resolve access accurately, update usage safely, and return decisions quickly enough that paywall enforcement never slows the product path.
Dynamic metered paywalls authorize each paid action before the product incurs the cost.
That matters when the final cost depends on what happens during execution. An AI agent run might call multiple tools, an LLM request might use more tokens than expected, and a compute job might scale with input size.
The paywall has to decide before the action starts, even when the exact cost is still unknown.
There are 2 common patterns:
Both patterns need the same core infrastructure:
Latency matters here. Cache hits should resolve from local infrastructure, such as Redis. Cache misses can fall back to a central service with a configured timeout. The key is keeping the paywall decision fast enough that enforcement does not slow the product path.
Ledger accuracy matters too. Once credits are deducted per request, a simple counter is no longer enough. Engineering needs an append-only record of what was reserved, spent, refunded, expired, or added.
For enterprise accounts, that ledger becomes part of the customer experience. You need to see which user, agent, workflow, or department consumed the allocation. Finance needs a record that matches the customer’s balance.
That is where dynamic metered paywalls become infrastructure. The UI shows the paywall, but the real work happens in the entitlement check, the usage meter, and the credit ledger behind it.
The capabilities below are what separate dynamic paywall infrastructure that holds up in production from implementations that create new problems as the product scales.
The further along the product is, the more each of these becomes a hard requirement. A team that builds a custom entitlement layer early in the product lifecycle often discovers at scale that the ledger was not append-only, the cache was not consistent, or the tenancy model was flat.
Rebuilding under load is the expensive version of that lesson.
Dynamic paywalls work when the enforcement model is architectural.
The entitlement layer owns access decisions, runs checks in the request path before actions execute, and keeps limit and offer configuration out of application code entirely. The paywall becomes a surface for a decision the infrastructure already made.
For teams building from scratch, a well-abstracted in-house entitlement service holds fine for a straightforward product. The inflection point is enterprise, with team-level allocations and real marginal costs per request.
Stigg is the usage runtime for AI products. Entitlements, credits, usage limits, and spend governance are enforced synchronously in the request path.
You don't need to adopt the full stack at once. Each component, like entitlements, credits, metering, and billing sync, can be integrated separately through a single integration point.
Key capabilities for engineering teams:
If you want the entitlement layer production-hardened from day one, the Stigg docs are the right next step.
A static paywall checks permissions once, typically at login or page load. A dynamic paywall evaluates entitlements before each relevant action, using live usage data so access can change instantly as limits, balances, or customer actions change.
Dynamic paywalls drive revenue by presenting upgrade offers at the moment customers reach a usage limit or try to access a premium feature. Showing relevant offers during the workflow typically converts better than generic upgrade prompts or hard blocks after access ends.
Billing software records usage and generates invoices. Dynamic paywalls decide whether a customer can perform an action in real time, based on current entitlements and usage. Billing tracks what happened, while dynamic paywalls control what can happen next.
Dynamic metered paywalls enforce access based on real-time usage before each billable action. They are essential for AI products, APIs, and other usage-based services where costs vary by request, ensuring customers cannot exceed their available balance or usage limits.
Yes. Dynamic paywalls work alongside Stripe by controlling access in real time, while Stripe handles payments and invoicing. The entitlement layer decides whether an action is allowed, and Stripe bills for what the customer uses.
