How to Design a Pricing Model That's Flexible and Scalable for AI Products
We hear a version of the same story over and over in customer calls.
A founder has a usage-based product in the market. They have some customers. Their pricing "works" — in the sense that money is coming in and the product is shipped. But when you ask how they're tracking usage, enforcing limits, or calculating margins? The answer is almost always some version of: "We build an in-house solution that works for now".
That's not a failure. That's just how early-stage companies survive. You hack things together. You make it work. But at some point, usually right before a major product launch or a new set of features hits the roadmap, that manual scaffolding starts to crack.
This post is about how to think through pricing before it becomes a crisis. What the data says. What we're seeing from companies in the field. And what it actually takes to build a model that can grow with you.
Why Pricing Keeps Getting Harder for AI Companies
Traditional SaaS had it relatively easy. Your marginal cost per user was close to zero. You could charge a flat monthly fee, set your tiers, and call it a day.
AI products don't work that way. Every API call costs money. Every model inference burns compute you're paying for. Every token processed is a line item on your cloud bill. Your cost structure is fundamentally consumption-based — which means your pricing needs to be, too.
And yet most AI founders are still trying to force those variable costs into fixed pricing models. The result? Margin erosion, pricing confusion, and customers who are frustrated because their bill doesn't match what they expected.
According to OpenView Partners, 61% of new B2B SaaS products are now exploring usage-based pricing — but adoption is still lagging behind where the market is heading. And a16z is clear: AI is actively driving a shift away from pure subscription models toward usage-based and outcome-based pricing.
The companies that figure this out early have a serious competitive advantage. The ones that don't end up renegotiating with every enterprise customer, eating overages, and scrambling to fix their billing setup right before a big launch.
Three Models — and What Each One Is Actually For
1. Pure Subscription
You charge a flat fee per month (or per seat). Customers know exactly what they're paying. Sales is easier. Revenue is predictable.
The problem: if your costs are variable, your margins aren't. You end up subsidizing your heaviest users and undercharging your lightest ones. At scale, this becomes a profitability problem.
When it works: Very early stage, when you're still learning your usage patterns. Or for B2C products where simplicity of pricing is a purchasing decision driver.
2. Usage-Based Pricing
Customers pay for what they use. You align revenue with value delivered. Margins hold up even as usage scales.
The problem: customers hate unpredictable bills. Sales gets harder. Finance teams at bigger companies struggle to budget for consumption-based software. And you need real infrastructure to track, enforce, and bill for usage accurately.
When it works: Infrastructure and API products, dev tools, any product where the user is another piece of software (not a person clicking around).
3. Hybrid Pricing — Where Most AI Companies End Up
A base platform fee (predictability for the customer) plus usage-based charges above a threshold (protection for your margins). Often layered with credits, top-up options, and enterprise-level overrides.
According to a16z's framework, usage-based pricing tends to work best when the end user is software — not a human. For human-facing products, pure subscription is often cleaner. But for most AI products today, the right answer is somewhere in the hybrid middle.
OpenView's benchmark data shows that 86% of SaaS companies valued above $100M use at least three dimensions in their pricing structure, and companies running multi-dimensional models show 34% higher LTV/CAC ratios than those using simpler models.
The most popular structure in 2025, per multiple industry reports: a monthly base fee, a credit pool, overages billed as needed. It's not revolutionary. But executing it well — especially as your product evolves — is harder than it sounds.
What We're Actually Seeing in the Field
We talk to founders at usage-based companies every week. A few patterns show up constantly.
The "back of the napkin" problem. A founder building an integration-heavy SaaS product told us recently that their pricing setup is "just a lot of manual calculators." Their team tracks usage through a basic tool, the founder needs a special login from their co-founder to see the metadata, and there's no clear dashboard showing per-customer margin. It works — until it doesn't. They're planning to launch two new add-on features in Q3, which will open new markets and make usage data far more important. The manual setup won't survive that.
The tier trap. Several companies we've spoken with built what felt like a solid pricing structure — usage buckets with auto-bumps after consecutive overages. Logical. Simple. Explainable. And then a couple of enterprise prospects came in with completely different requirements: percentage-of-contract-value pricing, custom usage thresholds, per-customer exceptions. The existing structure couldn't handle it without manual overrides for every deal.
The "eating it" overage problem. When customers blow through their usage limits — especially unexpectedly — someone has to absorb the cost. For most early-stage companies, that means the founder eats it, then figures out what to add to the contract going forward. One company we spoke with had an overage "significant enough" before finally building protective clauses into their customer contracts.
The pricing lag. Bigger companies — Notion, Salesforce, Miro — can introduce AI features and leave them un-monetized for a year while they learn usage patterns. They're treating early AI adoption as a loss leader. Early-stage companies can't do that unless they have a war chest. Which means you need to understand your usage data before you commit to a pricing model — not after.
How to Actually Design a Flexible, Scalable Pricing Model
Here's the framework we've built Limitr around, and what we recommend to every founder we work with.
Step 1: Start in Observe Mode
Before you commit to a scalable pricing structure, you need real usage data. What features are your customers actually using? Which ones are driving cost? What's the distribution of usage across your customer base — do a few heavy users account for most of your infrastructure spend?
You can't answer these questions without instrumentation. And most early-stage companies don't have it.
The approach that works: instrument your product to track usage at the feature level before you monetize it. Know what a "unit" of value looks like in your product. Know what it costs you. Then build your pricing around that.
Step 2: Design Your Pricing as a Policy, Not a Codebase
The biggest scaling problem with pricing is that most teams bake it into their code. A new tier means a new release. A limit change means a hotfix. An enterprise exception means a custom branch.
That's a nightmare. Pricing should be a configuration you can change in minutes — not a deployment you have to schedule.
The mental model that works: think of your pricing as a document. One document that says: who can access what, up to what limits, at what cost, with what overrides. Any change to that document should propagate immediately to your product, your billing, and your customer-facing UI — without touching your codebase.
Step 3: Build for the Customer You Don't Have Yet
Early customers often accept rough pricing because they like you and they want the product to work. Enterprise customers — or any customer who's actually going to scrutinize the contract — won't. You need to be able to handle:
- Custom limits per customer
- Discounts and promotional pricing
- Soft limits with overage billing vs. hard limits with denial
- Top-up credits for customers who want to buy more
- Per-feature pricing as your product expands
If your pricing infrastructure can't do any of those things in minutes, you'll lose deals or you'll paper over them with manual exceptions that compound over time.
Step 4: Align Your Pricing Unit with Your Value Unit
This sounds obvious but most teams get it wrong. Your pricing unit should map to the thing your customer cares about — not the underlying cost to you.
If you're a customer success tool, don't charge per API call. Charge per customer interaction, or per seat, or per outcome. If you're a developer tool, tokens or compute units might actually map well. If you're integration infrastructure, active integrations or syncs per month is probably closer to the value.
The rule of thumb from a16z: if your end user is a human, pricing by usage is harder to sell. If your end user is software, consumption pricing is more natural and expected.
Step 5: Don't Freeze Your Pricing Before You Know Your ICP
One insight that comes up repeatedly when talking to pricing experts: most early-stage companies lock in a pricing model before they've found their true ICP. Then they have to renegotiate with every enterprise customer because the model doesn't fit their purchase process.
The solution: build pricing infrastructure that's flexible enough to let you run experiments — different tiers for different segments, pilot pricing for design partners, outcome-based pricing for high-value deals — without requiring engineering work every time. Pricing is a product decision. It should be treated like one.
The Cost of Getting This Wrong
If you're thinking "we'll figure this out later" — here's what "later" actually costs.
Margin erosion. Heavy users on flat pricing tiers are often unprofitable. Without per-customer cost visibility, you won't know until you do the math — and by then you've made commitments you can't easily unwind.
Enterprise deals lost. Enterprise buyers often have procurement requirements that flat-tier consumer-style pricing can't satisfy. If you can't offer custom limits, volume discounts, or usage-based commitments, you'll lose deals to competitors who can.
Engineering tax. Every pricing change that requires a code change is engineering time that didn't go toward the product. This compounds. Teams that treat pricing as infrastructure from the start spend dramatically less time firefighting.
Forecasting blindness. If you don't know your per-customer margin, you can't model your business accurately. You can't tell investors a credible story about unit economics. You can't price your next feature correctly.
The Bottom Line
Pricing flexibility isn't a nice-to-have. For AI companies — where your cost structure is inherently variable — it's a core part of your product infrastructure.
The companies getting this right aren't doing anything exotic. They're starting with real usage data. They're treating pricing like a config, not a codebase. They're building enforcement and billing into their product from the start, rather than bolting it on after they've already made promises they can't keep.
The companies getting this wrong are doing a lot of back-of-the-napkin math, manual Stripe configurations, and praying their heavy users don't notice their margins.
You already know which camp you want to be in.
Sources: OpenView Partners — State of Usage-Based Pricing (https://openviewpartners.com/blog/state-of-usage-based-pricing/) | a16z — AI Is Driving a Shift Towards Outcome-Based Pricing (https://a16z.com/newsletter/december-2024-enterprise-newsletter-ai-is-driving-a-shift-towards-outcome-based-pricing/) | a16z — Usage-Based Pricing: Our Rule of Thumb (https://a16z.com/usage-based-pricing-rule-of-thumb/) | a16z — Pricing & Packaging Your AI Product (https://a16z.com/pricing-packaging-ai-b2b-prosumer/) | Metronome — AI Pricing in Practice: 2025 Field Report (https://metronome.com/blog/ai-pricing-in-practice-2025-field-report-from-leading-saas-teams)