The short version of how you get that under control: measure margin per account, per feature, and per vendor — not just cost. Set enforcement limits that guarantee your worst case. Then price so revenue moves with usage instead of trailing behind it.

Cost-to-deliver is the metric most teams reach for first, and it's a good start. But it's incomplete, because it's missing revenue. Controlling cost alone only ever caps your downside. The number that actually gives you control is margin-to-deliver.

Margin-to-deliver is the share of what you charge for a unit of delivered value that you keep after the vendor cost of producing it — (charged − overhead) / charged — measured per account, per feature, or per vendor.

Optimize margin-to-deliver and you've got two levers to pull: enforcement and pricing. Here's how we think about both, and the order we'd tackle them in.

Usage Observability​

An effective control strategy starts with observation. That's why we built an observe mode directly into our usage limits — you can't control what you can't see.

Vendor dashboards and API key segmentation might get you through the early days, but that approach falls apart the moment you need per-account, per-vendor, per-feature cost and margin analysis. If you don't believe that yet, check back in a few months once your product's grown up a bit.

The number you're after is margin-to-deliver. Here's an example:

Single account, per-feature usage, last 24 hours (2 vendors, 1 pipeline)​

• Claude Sonnet delivered: 35.67MTok
• Google Gemini delivered: 42.5MTok
• Outcomes delivered: 2,493
• Charged: $53.78
• Overhead: $42.45

An outcome here is one pipeline run. It may or may not mean anything to the customer — it means something to us.

Cost-to-deliver: $42.45, or $0.017 per outcome.

Revenue-per-outcome: $0.0216, so margin-per-outcome — (charged − overhead) / charged — comes out to 21.1%.

On average, every successful run nets us about 20% margin, for this account.

Now we have real numbers to work with. How much lower are we willing to let that margin go? How many more runs before it hits zero, or goes negative? Would a usage limit protect the bottom line, and should every plan or contract get one?

Attributing raw usage to outcomes​

The hard part is typically the mapping. A pipeline run generally isn't just one call — it's several, possibly across multiple vendors, and you need to know which outcome each one belonged to before any of the above means anything.

In Limitr, an outcome is just another credit, tracked the same way tokens are. Every allow(...) call can carry metadata, and it's a common pattern to attribute usage within it, rolling usage up per agent, per feature, via region, the customer's team, or even per run margin and spend data using spend caps.

We can do this because Limitr is a local, context-aware engine that can track state over many enforcement checks. Pricing stays accurate with or without any of it, but the metadata is what lets you slice the analytics afterward. It's what makes a line item like "this pipeline consumed 132MTok of Sonnet" possible.

Usage Enforcement​

Once you can see margin-to-deliver per account, feature, and vendor, the first real lever you have to control it is enforcement — deciding what a user has access to and how much of it.

Single account on a "pro" plan @ $200/mo (flat or seats)​

• AI pipeline @ $0.017 avg cost-to-deliver per outcome
• AI data aggregation @ $0.042 avg cost-to-deliver per refinement

$200/mo covers 11,764 pipeline runs at that cost. This account used 2,493 in 24 hours — a little over 4 days of runway, nowhere near a 30-day target. Left alone, this account pushes margin negative.

The simplest fix, without touching price: cap usage. One option is to limit the pro plan to 392 pipeline runs a day, and cut off data aggregation entirely. Worst-case margin-to-deliver is now 0% — you'll never lose money on this feature or account again.

But you may not make any money on it, either.

Usage Monetization​

At this point, the case for usage-based pricing should be clearer. You want revenue to scale with overhead, so margin-to-deliver becomes something you set and optimize through revenue, not just something you defend by cutting cost.

There's more than one way to do this — plenty of other posts cover pricing strategy on its own. But every approach depends on being able to analyze and enforce usage first, which is the whole point of the last two sections.

A few of the options, for the example we've been using:

• Credit model — flexible, supports top-ups, but can be confusing for users when the ROI isn't obvious
• Cost-plus-margin — clean and accurate, but rigid, invoices that need explaining, hard to upsell, and it tells the customer exactly what your margin is
• Outcome-based — a middle ground, packaged in the customer's language, but harder to guarantee a positive margin-to-deliver on

These aren't mutually exclusive, and the right answer usually differs by feature, by vendor, and by contract. Your objective changes too — margin this month, adoption next. That's the actual argument for keeping the choice in a policy instead of in code: you shouldn't have to ship a release to change your mind.

Here's what that policy might look like for our "pro" plan:

Single account "pro" plan Limitr policy​

• Monthly subscription: $200/mo (override for annual contracts)
• Includes 5 seats, then $29.99/mo per additional seat (hard limit for annual)
• Includes 30MTok Claude Sonnet tokens/day, then $5/MTok over (hard limit override for margin control on annual + usage governor for SLA)
• Includes 40MTok Google Gemini tokens/day, then $4/MTok over (same overrides)
• Includes 500 AI pipeline runs/day, then $0.02/run over (set to observe + unlimited on enterprise + analytics)
• Includes 100 AI data aggregations/day, then $0.05/aggregation over (same)

The subscription and seats are doing a specific job here: they're the predictable floor that covers your fixed cost regardless of how the account behaves. Everything below them is the part that moves.

On the contract and invoice (anything presented to the customer), keep it to subscription, seats, and outcomes when possible — in the customer's language, framed as wins where you can. Average cost per outcome makes a good line item. Put the full cost breakdown further down if needed, in its own section, for whoever wants to dig in.

Example account usage, 1 month​

• Claude Sonnet delivered: 1,080MTok — 900MTok included, 180MTok over
• Google Gemini delivered: 1,290MTok — 1,200MTok included, 90MTok over
• Successful AI pipeline runs: 30,000 — 15,000 included, 15,000 over
• Data aggregations: 4,500 — 3,000 included, 1,500 over
• Seats: 5, all included

Worth noting: that's about 1,000 pipeline runs a day, down from the 2,493 we saw in the first 24-hour window. Usage moves. A plan with a visible included amount and a rate past it changes how an account behaves in a way a flat $200 never does — which is exactly why you want to be watching margin-to-deliver continuously, not modeling it once.

Invoiced​

Usage details​

AI Pipeline Runs — $1,220.00

Data Aggregations — $415.00

Overhead for the month came to $699 — 30,000 runs at $0.017 and 4,500 aggregations at $0.042. Against $1,835 charged, that's a margin-to-deliver of 61.9%, up from the 21.1% we started with. Nothing got cheaper. Revenue was just allowed to move with the usage driving the cost.

The included usage gives you a good baseline margin-to-deliver, depending entirely on any base platform fees. The cost vs price per credit changes the margin-to-deliver for every credit beyond included limits. And separating internal/external outcomes vs vendors vs included provides flexibility per account, feature, and vendor to move margin-to-deliver according to your goals.

Two levers, one usage policy​

Cost-to-deliver tells you what an account costs. Margin-to-deliver tells you whether it's worth having, and gives you the numbers you need to actually stay in control.

Enforcement sets your baseline. A limit is a guardrail around the worst case. Cap pipeline runs at 392/day and you've decided, in advance, that this account cannot lose you money. It holds whether anyone's watching or not.

Pricing moves that baseline. Charge for overage and revenue rises with cost instead of being eaten by it. That's the 21.1% → 61.9% swing above.

Enforcement without pricing protects your margin by refusing actions — a 0% floor and a hard cap, for example. For some situations, like agent tool calls or the time an agent gets to converge on a turn, this layer of control makes sense regardless of pricing.

Pricing without enforcement can scale revenue with cost, right up until one run consumes 300x more AI overhead than accounted for.

Both require per-account, per-feature, and per-vendor observability. You can't set a limit you can't measure against, and you can't price an outcome you can't count.

Which is where this usually falls apart. Analytics sit with one vendor, limits sit in application code, prices sit in the billing system — and the three drift. The number you analyzed isn't the number you enforced on, and neither one is the number you invoiced.

This is what we built the Limitr policy for. One document defines the credits, what they cost you, what you charge for them, what each plan includes, and what happens at the limit — observe, soft, or hard.

That same document is what executes at the moment of the call. So the margin you're analyzing, the limit you're enforcing, and the line item you're invoicing all come out of one place, in real time, and they can't drift apart.

To see it in action, check out the live monetization demo that lets you play with a simple policy, tracking actual usage right here in your browser.

At runtime is about timing. The check happens while your code runs, instead of in a nightly job or at month-end.

A runtime is a thing. An execution environment that loads code and runs it.

We mean the second one. Your pricing policy is a document with logic in it, and that logic runs inside your process. Not a fast API call. Not a cached copy of your limits. The policy itself, running where your code runs.

What embedded actually means​

Limitr policies are written in Stof, an open-source data runtime that's a superset of JSON plus one thing that matters here: a document can carry functions, not just fields.

So a policy isn't config that our engine interprets according to its own rules. It's a document holding both the numbers and the logic that acts on them.

policy: {
    plans: {
        pro: {
            label: "Pro Plan"
            entitlements: { analytics: {} }
        }
    }
    customers: { john: { plan: "pro" } }
 
    fn has_analytics(id: str) -> bool {
        const customer = self.customers.get(id);
        const plan = self.plans.get(customer.plan ?? 'pro');
        ?plan.entitlements.contains('analytics')
    }
}

The Stof runtime is Rust compiled to WebAssembly. Limitr embeds it in your application, and it executes that document — sandboxed, in-process, on every call. The policy is data that travels. The runtime is what runs it.

Which means your pricing logic sits on your side of the network, unique to you, and always under your control. As such, it's context-aware and can hold state across a sequence of calls instead of answering one question at a time.

Here's what we do with that.

Monetize: charge in units your customers understand​

Vendors bill you in tokens, seconds, pages, requests. Your customers don't buy any of those. They buy documents processed, calls handled, deals closed. Sometimes they just want to know the dollar number.

Limitr converts between them while usage happens. The rates live in the policy, so a token count becomes credits becomes dollars at the moment of the call, not when the invoice runs.

That conversion has to happen in-process, because it needs the raw usage and that customer's rates in the same place at the same time. An outside service can convert numbers you send it afterward. It can't be inside the current pipeline context.

This means the invoice is built from the same numbers your product already enforced against. Nothing gets reconstructed at month-end, and the line items make sense to the customer without a footnote.

Control: one spend cap across an entire pipeline​

Say an agent makes three calls in a single run — a model provider, a search API, a document parser. Three vendors, three unit systems, three prices. Now put a $2.00 ceiling on the run.

A remote service can approve each call on its own. The hard part is holding the running total for that specific run, because the state lives in your process and every check is a round trip to something that doesn't have it. You either track it yourself, which means you wrote the enforcement, or you find out after the run finished.

Embedded, the cap is just a number the policy carries as the run goes. The third call gets denied because the first two already spent. And it works across all three vendors because the exchange already put them in the same unit.

This enables caps that hold across a whole pipeline, not one call at a time. A faster API doesn't get you there.

Analyze: know what a run costs, not just what a call costs​

Per-call margin is relatively easy. Report a cost and a price with every event and anything can add them up.

The questions worth asking are shaped differently. What did this run cost? What's our margin on a success versus a failure? Which agent is expensive? Is this customer actually profitable at the rate we gave them?

Those need context that only exists while your code is running — where a run started and stopped, which calls belonged to it, whether it worked, which agent made them. A reporting service receives events. It doesn't know what a run is unless you tell it, and once you've built the run boundary and the attribution chain to tell it, you've built the analytics layer and outsourced the addition.

Our runtime is already in the pipeline, so it sees the run. And the exchange already put every vendor's usage into one unit, so the run's cost is a single number instead of tokens plus seconds plus pages.

This enables us to track cost per outcome instead of just cost per call.

Why the bar should move​

None of this is a speed claim. Just being fast doesn't fix it. The limit is that context doesn't survive a round trip — your pipeline state, your call sequence, your costs aren't on the other end of that request unless you sent them, and if you're sending them, you're doing the work the enforcement layer was supposed to do.

So we're picky about the word. "At runtime" tells you when a check happens. "A runtime" tells you where your logic lives. The second is a much bigger commitment, and it's the one that decides whether a pricing system can hold state across a run, convert units mid-flight, and tell you your margin before the invoice shows up.

When Limitr says runtime, we mean the noun.

If you're looking at tools that use the word, ask where the logic actually runs.

Traditional SaaS pricing — flat tiers, per-seat subscriptions — was built for near-zero marginal cost software. It made sense when the cost to serve a new user was effectively nothing. AI and agentic products don't work that way. Every model inference costs money. Every API call has a price. Your most active customers might cost you 10x what your least active ones do.

The result? Margin erosion that's invisible until it's material. Pricing structures that break the moment you land a large customer or ship a new feature. Engineering teams spending 25–40% of their cycles on billing logic instead of building the actual product.

This guide exists to help you avoid that. Whether you're pre-revenue designing your first pricing model, or Series B+ cleaning up years of pricing debt — the playbook is the same: get real usage data first, build pricing as infrastructure (not code), and charge for the value you actually deliver.

1. The State of AI Pricing in 2026​

The pricing landscape has shifted dramatically in the past 18 months. AI is no longer an add-on feature. It's the product. That means pricing AI correctly isn't a nice-to-have — it's survival math.

The numbers tell the story:

• 61% of new B2B SaaS products are now exploring usage-based pricing, up from 49% just a year ago (OpenView Partners: https://openviewpartners.com/blog/state-of-usage-based-pricing/)
• 80% of enterprises miss their AI cost forecasts by more than 25% (Mavvrik AI Cost Governance Report: https://www.mavvrik.ai/ai-cost-governance-report/)
• 84% of companies report significant gross margin erosion tied to AI workloads — and for companies where 50%+ of customers use AI features, that margin hit reaches 16% (Mavvrik)
• Companies using per-seat pricing for AI products report 40% lower gross margins and 2.3x higher churn than those on usage-based or hybrid models (Bessemer Venture Partners: https://www.bvp.com/atlas/the-ai-pricing-and-monetization-playbook)
• 86% of SaaS companies valued above $100M use at least three dimensions in their pricing structure, and those companies show 34% higher LTV/CAC ratios (OpenView Partners)

What's happening is a full-category repricing event. The companies that get ahead of it now will have a structural advantage over those scrambling to retrofit pricing later.

Why this hits early-stage companies hardest:

Large, well-funded companies can absorb AI feature losses as a growth investment — treating early AI adoption as a loss leader while they figure out the right model. Early-stage startups can't do that without significant runway. If your per-seat pricing is subsidizing heavy AI users, you're funding their usage out of your capital.

That's not a business model problem. It's a pricing infrastructure problem. And it has a concrete solution.

2. Three Pricing Models Every AI Startup Needs to Understand​

There's no universally "correct" AI pricing model. There are more out there than these, but we'll focus on three frameworks every AI founder needs to understand — and a clear set of signals that tells you which one you actually need right now.

Model 1: Pure Subscription (Flat Tiers)

You charge a fixed monthly fee per seat or per plan tier. Simple. Predictable. Easy to sell.

The problem: if your underlying costs are variable — and for AI products, they always are — flat pricing creates margin instability. Your lightest users are highly profitable. Your heaviest users may be actively unprofitable. You're averaging across them, which masks the problem until it's too late.

When it works: Pre-revenue, when you're still learning your cost structure. Or for B2C products where pricing simplicity drives conversion. Or when AI is a small, incidental feature rather than the core value driver.

Model 2: Usage-Based Pricing (Consumption)

Customers pay for what they use. Revenue scales with value delivered. Margins stay consistent because costs and revenue move together.

The problem: unpredictable bills create friction in sales and procurement. Enterprise finance teams struggle to budget for variable software spend. And you need real metering infrastructure to do this right — which most early-stage companies don't have yet.

When it works: API products, developer tools, infrastructure — any product where the end user is software rather than a human. According to a16z (https://a16z.com/usage-based-pricing-rule-of-thumb/), usage-based pricing fits naturally when the buyer is technical and the unit of value maps cleanly to consumption.

Model 3: Hybrid Pricing (Base Fee + Usage)

A fixed platform fee gives customers cost predictability, while usage-based components protect your margins and align revenue to actual value delivered.

The base fee covers access, support, and SLA commitments. The usage component captures the incremental value of heavy usage — model calls, API hits, seats, or AI credits.

This is where most AI companies ultimately land. OpenView Partners data shows the most popular structure in 2025 is: monthly base fee + a credit pool + overages billed as needed.

When it works: Series A and beyond, when you have enough usage data to set limits intelligently and enough deal volume to see patterns across your customer base.

What most companies get wrong:

They choose a model before they have data. They lock in tiers based on intuition, launch, and then discover that 20% of customers are generating 80% of their infrastructure costs. Renegotiating is painful. Repricing is a churn risk.

The better path: start collecting usage data on day one, even before you monetize it. When you have the data, the right pricing model becomes obvious.

3. The Engineering Cost of Getting Pricing Wrong​

Most founders think about pricing mistakes in terms of revenue left on the table. The more immediate cost is usually operational — specifically, engineering time.

The hidden engineering tax

When pricing logic lives in code, every pricing change is an engineering task:

• New tier? New release cycle.
• Enterprise exception? Custom branch.
• Overage rule? Someone needs to write it, test it, and deploy it.
• Customer wants a usage dashboard? Another sprint.

This is the default state at most early-stage AI companies — and the data makes the cost visible:

• Companies building billing and enforcement infrastructure in-house typically allocate 25–40% of engineering resources to billing-related work (Chargebee: https://www.chargebee.com/blog/ai-monetization-billing-infrastructure/)
• Building metering, enforcement, and customer billing dashboards to production quality can take 6–12 months and costs over $200K in engineering time
• Companies that regularly review and optimize their pricing see 30% higher growth rates than those that don't (OpenView Partners)

Every week your engineering team spends on pricing infrastructure is a week they're not building product.

What "pricing debt" looks like in practice:

In conversations with usage-based founders, the same story surfaces repeatedly. A founder is doing back-of-the-napkin math to calculate margins per deal. They need a special login from their CTO to see usage metadata.

This isn't a sign of a poorly-run company. It's a sign of a company that moved fast to get customers — and deferred the infrastructure problem.

But at some point, usually right before a new product launch or a new sales motion, the manual scaffolding cracks. An enterprise prospect asks: "Can you do custom limits, credit bundles or topups?", and suddenly the manual setup can't act fast enough.

The compounding cost of waiting:

• Margin erosion: At 16% margin erosion, a $20M ARR company loses $3.2M in annual gross profit it could have kept.
• Forecasting blindness: Without per-customer cost visibility, you can't identify which customers are profitable, which are loss leaders, or when to trigger upsell conversations.
• Enterprise deals lost: Custom pricing requests you can't fulfill fast enough cost deals. The longer your pricing change cycle, the more leverage buyers have.
• Churn from model mismatch: 2.3x higher churn for companies on misaligned pricing models compounds over time.

4. Five Steps to a Flexible, Scalable Pricing Model​

Here's the framework — and what we'd recommend to any AI founder working through this for the first time or the fourth time.

Step 1: Start in Observe Mode Before You Monetize

Before you charge for usage, measure it. Add instrumentation to understand what features customers use, how often, and at what cost to you. This data is the foundation of every pricing decision you'll make.

Most teams skip this step because they're in a hurry. Don't. The companies that have this data design pricing with confidence. The ones that don't are guessing.

Things to track from day one:

• Feature-level usage per customer
• Cost per unit of value (per API call, per model inference, per active session)
• Distribution of usage across your customer base — how top-heavy is it?
• Which features drive retention vs. which are rarely touched

Step 2: Design Pricing as a Policy, Not a Deployment

Your pricing model should live in a single, versioned configuration — not scattered across hundreds of code files. That configuration should be readable by GTM and Finance, not just engineers. And it should be updatable without a code release.

The mental model: imagine a document that says exactly who gets access to what, at what limits, with what pricing rules. Every change to that document propagates instantly to your product, your billing, and your customer-facing UI.

When pricing lives in code: changes take weeks, exceptions become technical debt, GTM can't move without engineering.

When pricing lives in a policy document: changes take minutes, exceptions are configurations, and Finance and Product can own pricing decisions directly.

Step 3: Build for Customers You Don't Have Yet

Early customers are forgiving. Enterprise customers aren't. Build your pricing infrastructure to handle what a demanding enterprise buyer will ask for — before you're in the room with them.

Your pricing model should be able to support:

• Custom per-customer limits, both soft (invoice for overage) and hard (deny any overage)
• Overage billing vs. hard cutoffs, configurable per plan
• Volume discounts and promotional pricing
• Top-up credits and add-on features
• Real-time usage visibility for customers, not just your team
• Audit trail of pricing changes over time

If your current setup can't do any of these things in under 10 minutes, you'll lose enterprise deals or paper over them with manual exceptions that compound into maintenance nightmares.

Step 4: Align Your Pricing Unit to Your Value Unit

Your pricing unit — the thing you charge for — needs to match the unit of value your customer actually experiences. This is the hardest step and the most important one.

A few examples:

• Customer success platform → charge per customer interaction, not per API call
• AI writing tool → charge per document or words generated, not per token
• Integration infrastructure → charge per active sync or integration, not per request
• Developer API → tokens or compute units are natural and expected

The test: if a customer can explain your pricing in one sentence, and it maps to how they think about the value they receive, you have the right unit. If they have to understand your cost structure to understand your pricing, you don't.

Step 5: Test Pricing Without Engineering Sprints

Pricing is a product decision. It should be iterated on like one — quickly, with data, without requiring engineering intervention every time.

This means:

• Testing different limits for different customer segments
• Piloting new tier structures with a subset of customers
• Moving a customer to a new plan in minutes, not days
• Reverting pricing changes if you make a mistake

OpenView data shows a 30% higher growth rate for companies that regularly optimize pricing. The constraint for most teams isn't strategy — it's the time and cost of making pricing changes.

5. Stage-by-Stage Pricing Playbook​

What pricing decisions matter most depends on where you are in your company's growth. Here's how to think through each stage.

Pre-Seed and Seed (0–$500K ARR)

Your primary goal isn't optimizing pricing. It's learning.

• Use flat-tier or founder-negotiated pricing to close your first 10–20 customers
• Instrument everything: add usage tracking from day one, even if you're not charging for it yet
• Don't build billing infrastructure from scratch — use Stripe's defaults and reconcile manually if needed
• Identify your pricing unit: what one thing do your best customers have in common in terms of usage?
• Avoid long-term contracts that lock in pricing before you understand your cost structure

Series A ($500K–$5M ARR)

You have customer data. Use it.

• Review per-customer margin for every account — if any are unprofitable, understand exactly why
• Begin transitioning toward hybrid pricing: a base fee plus usage-based components
• Build or buy metering infrastructure — this is no longer optional at this stage
• Define your standard pricing tiers, but build in flexibility for enterprise exceptions
• Instrument your pricing model so non-engineers can make changes without a deployment

Series B+ ($5M+ ARR)

Pricing is a growth lever, not just a billing question.

• Run structured pricing experiments: A/B test tiers, limits, and packaging for new segments
• Expand to outcome-based components for enterprise deals where value is clearly measurable
• Build customer-facing usage dashboards — enterprise buyers want visibility into their own spend
• Connect pricing changes to revenue impact: if you increase a limit, what's the ARR effect?
• Review pricing quarterly — every major AI model release is a potential re-pricing event

6. Metrics That Actually Matter​

Most pricing conversations focus on revenue metrics. The ones that actually tell you whether your model is working are cost metrics.

Gross margin by customer segment

Not just overall gross margin. Break it down by plan, usage tier, and customer cohort. If your enterprise customers are less profitable than your SMB customers, that's a pricing problem, not a sales problem.

Usage distribution

How concentrated is usage in your top 10% of customers? If your top decile accounts for more than 60% of compute costs, you likely have a pricing structure problem.

Time to pricing change

How long does it take from "we want to change this limit" to the change going live in production? If the answer is more than one business day, your pricing is baked into your codebase.

Overage rate

What percentage of customers are regularly exceeding plan limits? High overage rates signal either repricing opportunity (limits are too low) or churn risk (customers would leave if you enforced them).

Pricing exception rate

How often do you make manual per-customer pricing exceptions? More than 20% is a sign your standard pricing model doesn't fit your ICP.

Frequently Asked Questions​

What's the right time to switch from flat-tier to usage-based pricing?

When you have enough usage data to set limits intelligently and when flat-tier subsidies are materially affecting your gross margin. For most teams, this happens somewhere between 20–50 customers.

How do you handle enterprise customers who want custom pricing?

Custom pricing should be a configuration, not a coding project. If making an exception for an enterprise customer requires an engineering ticket, you need better pricing infrastructure. The goal is to offer any customer any limit, discount, or usage structure in minutes.

Should we build our own billing infrastructure?

No. Building metering, enforcement, and billing infrastructure in-house is a short-term fix. The ROI almost never pencils out for companies under $10M ARR. Use infrastructure built for this purpose.

How should we think about AI pricing as model costs drop over time?

Your pricing model should abstract away from model costs entirely. Customers should pay for value received, not for your cost to deliver it. When model costs fall 50%, use that to improve margins or fund new features — don't automatically pass it through.

What's the single biggest mistake founders make with pricing?

Locking in a pricing structure before understanding usage patterns. The companies that get this right spend 2–3 months observing usage before they monetize it. The ones that get it wrong price on intuition, then spend 12–18 months unwinding structures that don't fit their actual customer base.

Sources

OpenView Partners — State of Usage-Based Pricing: https://openviewpartners.com/blog/state-of-usage-based-pricing/

Mavvrik — AI Cost Governance Report: https://www.mavvrik.ai/ai-cost-governance-report/

Bessemer Venture Partners — AI Pricing and Monetization Playbook: https://www.bvp.com/atlas/the-ai-pricing-and-monetization-playbook

a16z — Usage-Based Pricing Rule of Thumb: https://a16z.com/usage-based-pricing-rule-of-thumb/

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/

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)