Dynamic pricing for SaaS explained: the main types, real software and AI examples, pros, cons, and legal questions, and how to implement it in your product.
A model provider cuts its token prices, and your team wants to pass some of that on: a lower credit rate for the cheaper model, the same rate for the premium one, and launch pricing for new signups in two regions. Deciding all that takes an afternoon of meetings.
Shipping it takes weeks, because the old rates live in application code, the billing configuration, a paywall component, and a pricing page somebody hardcoded last year. That gap between deciding a price and applying it everywhere is the real work of dynamic pricing in SaaS.
This guide covers what dynamic pricing means for software, the main types, real SaaS and AI examples, the pros, cons, and legal questions, and how to implement it so a price change reaches the product without a code deploy.
Dynamic pricing in SaaS is a pricing approach where the price a customer pays changes based on factors like usage, customer segment, region, time, or demand. The list price is a starting point, and pricing rules decide what each customer pays and what they get for it.
In consumer markets, dynamic pricing usually means prices that move in real time, like airline seats or ride-hailing fares, and most SaaS products don't reprice by the minute.
In SaaS, it usually means prices and limits that vary by customer and change often, like per-unit rates that drop at higher volumes, regional price points, and AI credit rates that differ by model.
Dynamic pricing works by feeding signals into pricing rules, then applying the resulting price or limit everywhere the customer meets it: the pricing page, the paywall, the entitlement check in the product, and the invoice.
Making the pricing page, the product, and the invoice agree on those rules is an engineering problem, and it’s the part most SaaS teams underestimate.
The main types of dynamic pricing are usage-based, segment-based, geographic, time-based, demand-based, competitor-based, value-based, and cost-based pricing. Most SaaS products combine two or three of them.
Usage-based pricing charges customers for what they consume, like API calls, messages, compute hours, or tokens, so the bill moves with usage. It's the most common form of dynamic pricing in SaaS, and Stigg's guide to usage-based pricing covers the models in depth.
Segment-based pricing sets different prices for different customer groups, like startups, nonprofits, education, or enterprise accounts. Startup programs, education discounts, and custom enterprise contracts are all segment-based pricing.
Geographic pricing sets different price points by country or region, usually to match local purchasing power. A plan that's a small expense in one market can be out of reach in another, which is why price localization goes further than converting currencies.
Time-based pricing changes the price based on when someone buys or uses the product. Launch pricing, limited-time promotions, end-of-quarter discounts, and lower rates for off-peak or delayed processing all fall here.
Demand-based pricing raises or lowers prices as demand changes relative to available capacity. It's the model behind surge fares in ride-hailing, and in software it shows up mostly in infrastructure, where spare compute capacity is sold at prices that move with supply and demand.
Competitor-based pricing adjusts prices in response to what competitors charge. In SaaS, this tends to happen at the packaging level, like matching a competitor's free tier or included usage, and less often as automatic price changes.
Value-based pricing sets prices according to the value customers get, like hours saved or revenue generated. Stigg's guide to value-based pricing walks through how teams estimate that value.
Cost-based pricing ties the price to what each unit costs you to serve, which matters most in AI products where inference costs differ by model and change often. Credit rates that vary by model, or token-based pricing that passes through model costs, are both cost-based dynamic pricing.
Dynamic pricing in software shows up as per-model AI rates, discounts for work that can wait, spot compute, regional prices, and volume tiers.
It's spreading fastest in AI products, where ICONIQ's State of AI 2026 found consumption-based pricing among AI builders rose from 35% to 42% in six months.
Model providers charge a different rate for each model. Anthropic's Batch API takes 50% off input and output tokens for asynchronous requests, and OpenAI's Flex processing prices tokens at Batch API rates for lower-priority work.
That's cost-based and time-based pricing at once, since the price depends on which model runs the request and how quickly you need the answer.
Cloud providers sell spare capacity at prices well below on-demand rates, in exchange for the right to reclaim it. AWS lists EC2 Spot Instances at up to 90% off On-Demand prices, and Google Cloud Spot VMs at up to 91% off for many machine types.
Subscription apps often charge different prices by country to match local purchasing power.
Spotify Premium, for example, costs $12.99 a month in the US and ₹139 a month for Premium Standard in India (which is about $1.50 in October 2026), and software companies use the same approach with regional price points.
Prices are subject to change without notice. Always visit the official company websites for the most up-to-date pricing information.
Many API and infrastructure products drop the per-unit price as volume grows, so the 1,000,000th request costs less than the first. Tiered volume pricing is dynamic in the sense that each customer's effective rate depends on how much they use.
AI products often sell one credit balance that burns at different rates by model, feature, or task. A premium-model request might cost several times the credits of a smaller model's, and rates can shift with model costs while customers keep buying the same credits.
Stigg's guide to AI credits covers how those rates get set.
Dynamic pricing lets you match price to value, cost, and willingness to pay, but it also adds challenges for your customers and your systems.
Pros:
Cons:
Dynamic pricing is generally seen as fair when customers understand the rule and can predict their price, like volume discounts, regional pricing, or published per-model rates. It draws criticism when prices change in ways customers can't see, especially when they're based on personal data.
That's usually what people mean when they ask why dynamic pricing is bad. Surge fares and individualized consumer pricing have made buyers suspicious, so in SaaS the safest versions are the transparent ones, where the published rule applies the same way to everyone in the same situation.
Dynamic pricing is legal in the US, and no federal law bans changing prices based on demand, usage, time, or region. The legal risk is around pricing based on an individual's personal data, and competitors coordinating prices through shared algorithms.
For most SaaS pricing, like usage rates, published tiers, and regional prices, the personal-data rules don’t come into play, as long as you set prices independently of competitors. If you plan to set individual prices from personal data, especially for consumers, get legal advice first.
Implementing dynamic pricing in SaaS takes six steps: choose the signals, model prices and limits in one catalog, enforce them with entitlement checks, show changes through paywalls, handle variable-cost actions safely, and roll out changes with versioning.
Start with the inputs your pricing rules depend on, like usage, plan, customer segment, country, model, or time. Each signal needs a reliable source in your stack, so country needs a billing address or geolocation, and usage needs usage metering you can trust.
Plans, add-ons, limits, credit rates, and regional price points should live in one product catalog that the pricing page, the product, and billing all read from. If they don't, every price change turns into a search through the codebase.
Hardcoded plan logic is the usual trap. A few checks like plan === "pro" feel harmless at first, until Pro gets a new limit, one customer gets a contract override, a new add-on raises the cap, and old customers stay on legacy terms.
Plan checks end up spread across route handlers, frontend components, background jobs, and support scripts, so the application turns into the pricing system without anyone deciding it should.
An entitlement is the commercial allowance a customer has paid for, like a feature, a usage limit, or a credit balance. Before each relevant action, the product asks one question: can this customer do this right now, under their current plan, add-ons, trial, overrides, and usage?
An entitlement management system answers that question in the request path and returns enough context for the product to act:
{
"allowed": false,
"feature": "api_calls",
"limit": 10000,
"usage": 10000,
"remaining": 0,
"enforcement": "hard_limit",
"upgradePath": "pro",
"reason": "usage_limit_reached"
}
The tools most teams already have each cover part of this. Billing knows what the customer pays for, but it sees usage after the fact, so it can't block an action before it runs.
Feature flags control rollout state, so they can turn a feature on, but they usually don't know the customer upgraded three minutes ago, bought more credits, or has a grandfathered limit.
Feature gating tied to entitlements solves that, because the gate reads what the customer bought.
Dynamic paywalls are where a pricing change becomes visible inside the product. They check the customer's live entitlements before an action and show the right prompt, warning, or block based on the answer. Four kinds cover most products:
Because the paywall reads from the same entitlement check, a new price or limit shows up in the product as soon as the catalog changes.
When the cost of an action isn't known until it finishes, like an AI agent run that calls several tools or an LLM request with unpredictable output, the check has to happen before the cost is incurred. A common pattern looks like this:
This flow depends on atomic deductions across concurrent requests, idempotency when clients retry, and an append-only ledger finance can audit, since a simple counter drifts as soon as two requests hit the same balance. Stigg's guide to credit pricing covers the ledger side.
Dynamic pricing means prices change often, so every change needs a rollout plan. Versioned plans let you publish a new price to new customers only, migrate everyone at once, or test the change in one region or segment first.
Existing customers often keep their old terms for a while, and the entitlement layer is the right place to hold those legacy limits. Billing tracks what they pay, and the product still has to enforce what they were promised.
The infrastructure behind dynamic pricing has to make access decisions fast, accurately, and in sync with the catalog.
To check whether your stack is ready for dynamic pricing, count how many places your last price change touched: the pricing page, paywall copy, plan checks in code, billing configuration, and support scripts. Every place on that list gets edited again with each future change.
Dynamic SaaS pricing works when the price lives in one catalog and the product enforces it through one entitlement check. Stigg is the usage runtime that provides that layer for AI products, running entitlements, credits, metering, and limits in the request path alongside your existing billing.
With Stigg, engineering teams can:
It’s one platform, and teams often start with the capability their next pricing change needs, like credits or localization, then turn on the rest as they grow.
If your next price change already looks like a multi-team project, talk to a human about your stack, or start with the AI quickstart in the docs.
Businesses that use dynamic pricing include airlines, hotels, ride-hailing apps, retailers, cloud providers, and AI and API companies. In software, it most often shows up as usage-based rates, regional pricing, and per-model AI pricing.
Usage-based pricing is one type of dynamic pricing. Dynamic pricing covers any price that changes based on a factor like usage, segment, region, time, or demand, and usage-based pricing is the case where the factor is consumption.
Surge pricing is the demand-based form of dynamic pricing, where prices rise when demand outpaces supply. Most SaaS dynamic pricing works differently, since prices change based on usage, segment, or region more than minute-to-minute demand.
A static paywall checks permissions once, typically at login or page load. A dynamic paywall checks entitlements before each relevant action, using live usage data, so access changes as soon as limits, balances, or plans change.
Dynamic pricing in SaaS usually needs a product catalog, usage metering, an entitlement layer that enforces limits in the product, and a billing system that invoices from the same rules. Many teams also add a pricing page and paywall components that read from the catalog.
