Usage Based Pricing for Series A Startups (Guide)

You're at Series A, usage is climbing and each query or transaction changes what it costs you to serve customers. In this situation, pricing can scale with customer value instead of staying pinned to a flat seat count. 

This guide walks through what usage-based pricing (UBP) looks like in practice for Series A founders, covering the four main models, how they affect your fundraising metrics and the most common mistakes.

What Usage Based Pricing Means for Series A Founders

Usage-based pricing is a model where customers pay based on how much of your product they actually consume, rather than a fixed per-seat or flat subscription fee. Revenue scales directly with the value customers extract. The structural variants range from pure pay-as-you-go to hybrid approaches that combine a base subscription with metered charges on top. 

Pure pay-as-you-go pricing remains the exception; most software-as-a-service (SaaS) companies that have moved beyond flat subscriptions blend usage with a subscription floor. Hybrid models report the highest median growth rate in 2025, at 21 percent, surpassing subscription- and usage-based pricing. The market has converged on hybrid rather than pure consumption. 

Why the Shift Is Happening Now

Two forces dominate. First, artificial intelligence (AI) products carry real per-unit compute costs that don't map to per-seat economics, and when you charge a flat fee but incur variable inference costs per query, your margin becomes a function of usage volume rather than license count. 

Second, UBP embeds the land-and-expand motion at the pricing layer, while CFOs demand pricing that correlates cost with realized value even as corporate IT budgets grow at low single-digit rates annually.

Four Usage Based Pricing Models You Should Know

Each of these models works well in specific contexts. The right choice depends on your cost structure, your buyer profile and how much usage data you have today. Most Series A founders end up testing more than one before settling on a structure that fits.

Pure Pay-As-You-Go

Customers pay only for what they consume, with no base fee. Snowflake charges per credit, Twilio charges per message and most AI APIs charge per token. This structure works when your cost is directly variable, customer usage varies widely and the buyer is a developer who wants to experiment before committing. The downside is revenue unpredictability: pure pay-as-you-go pricing can create margin and forecasting challenges for AI companies.

Hybrid Pricing

A fixed software or seat fee provides a revenue floor, and a usage component captures expansion as customers grow. Hybrid adoption has accelerated quickly, with the share of SaaS companies running hybrid models rising from 49 percent to 61 percent in a single year, and hybrid has emerged as the market's convergence point. 

Vercel runs this model well: its Pro plan starts at $20 per month with usage charges for compute, bandwidth and function invocations that kick in beyond included limits, and the company serves more than 100,000 paying teams. CRV led Vercel's Series A and backed the company through its B, C, D and E rounds. We've watched hybrid pricing scale alongside a developer product up close.

Tiered Usage

This model buckets usage into fixed tiers with a set price per tier and no per-unit overage charges within a tier. It works best when customers have predictable usage patterns, when you want to eliminate bill-shock risk and when your buyer profile is small or mid-market. 

The structured upgrade triggers, where hitting a tier ceiling creates a natural expansion conversation, make this a clean model for sales-led motions. One caution at Series A: tiered usage requires enough knowledge of customer usage distribution to set tier boundaries correctly, so starting hybrid and migrating to tiers once you have cohort data is more practical.

Credit-Based Pricing

Customers purchase a pool of credits, and different actions consume different numbers of credits. Some companies use this model, including Salesforce. The benefit for AI startups is that credits let you change the underlying cost of actions as large language model (LLM) inference costs shift, without changing headline prices. 

Credits carry real risks, though: Salesforce's arc with Agentforce illustrates the tension. The product launched at $2 per conversation, moved to credits at $0.10 per action, then layered per-user licenses on top because CFOs needed a budgetable number.

How to Choose the Right Value Metric

A viable value metric has three properties: it's measurable, it scales with the value customers receive and customers understand it intuitively. Getting this wrong is the most consequential early mistake in a UBP implementation, because founders often pick a metric aligned with their own cost structure rather than one that reflects the value customers experience. 

The metric you choose becomes embedded in contracts, billing infrastructure and customer expectations, so changing it later is expensive.

The Copilot vs. Agent Distinction

Many AI founders stall at this distinction. Copilots, which are AI that assist a human user, map naturally to per-seat pricing because the human is still doing the work. Agents, which are AI that replace or augment a human function, map to consumption or outcome-based pricing because the agent is doing the work, and your product's position on this spectrum should drive your value metric more than any other factor. 

LLM APIs typically charge per token, AI agents replacing human functions charge per task or per resolution and coding assistants tend toward per-seat plus a usage add-on.

A Quick Gut Check

If a customer can't explain their bill to their CFO in a single sentence, the unit is too complex or too abstracted from value. Gross margin protection is a legitimate concern, but you should address it through rate-setting and tier design rather than metric selection. Running pilots to calibrate before committing to a metric turns your pricing decision from speculative to empirical.

How Usage-Based Pricing Reshapes Your Series A Metrics

Several Series A metrics change materially under UBP, including how investors read net revenue retention, gross revenue retention and the composition of your annual recurring revenue (ARR). Understanding these differences and having clean data that accounts for them is an operational necessity before your Series A pitch.

Net Revenue Retention

Net revenue retention (NRR) is one of the most important metrics investors examine for UBP companies. At the $1 to $5 million ARR range typical of Series A, a solid NRR is around 100 percent, while stronger performance is typically 110 percent or higher. 

Snowflake demonstrates the ceiling for what consumption-based NRR can look like, with NRR peaking at 178 percent in January 2022, and later reported at 126 percent as of January 2025, an exceptionally high level for a public SaaS company. Companies with NRR above 120 percent can trade at a 63 percent premium over the market median.

Gross Revenue Retention

Gross revenue retention (GRR) can vary based on customer behavior and pricing dynamics, especially during downturns. Investors will probe whether your NRR compensates for the lower GRR, so you need to model both and be prepared to explain the composition of each. 

UBP companies often see this gap widen because heavy users expand aggressively while marginal customers reduce usage rather than churn outright, which masks softening engagement in the GRR line.

LTV and ARR Composition

Lifetime value (LTV) calculations get harder under UBP because revenue per customer is variable and churn definition becomes ambiguous. A customer who reduces usage materially hasn't churned in the traditional sense, but has reduced their LTV. 

Your investors need to see the ratio of committed ARR to variable usage ARR, because a startup with 70 percent committed ARR and 30 percent usage ARR presents a different risk profile than one with 10 percent committed and 90 percent usage, even at identical total ARR.

Three Ways Usage-Based Pricing Implementations Stumble

The competitive edge in pricing comes from being able to change it quickly without breaking customer trust. Getting it right on the first attempt is rarely the differentiator. Among the top 500 SaaS and AI companies, there were more than 1,800 pricing changes in 2025 alone. Pricing iteration is the norm, not the exception.

Revenue Forecasting Difficulty

In many usage-based models, a small set of accounts drives a disproportionate share of revenue, and predicting which accounts will end up in that top cohort is genuinely hard. Committed-use agreements create a revenue floor, and at Series A account counts, a tight feedback loop between customer success and finance is practical and high-value. 

Mercury's pricing, which we know well from leading the company's Series A and participating in its B and C, addresses this tension by blending a free core product with per-transaction charges in its paid tier.

Customer Budget Anxiety

Customers operating on annual budgets can't calculate their spend the way they can with per-seat pricing. Many usage-based companies struggle with this communication problem;  metering complexity and customer comprehension consistently rank among the top blockers founders face. 

A useful mitigation is building real-time usage dashboards into the product, because discovering accumulated costs for the first time on an invoice is a trust-breaking event. Price caps, volume discounts or a base fee plus usage structure give buyers a worst-case number for budget planning.

Billing Infrastructure

Billing infrastructure is the most technically underestimated challenge for Series A startups. Your ability to change pricing metrics, launch new tiers or experiment with packaging is gated by what your billing system supports. Scaled companies that built billing systems in-house have sometimes needed engineering teams in the dozens to maintain those systems. 

At early ARR, building custom billing infrastructure often pulls scarce engineering away from the product itself. Stripe Billing works for teams with simpler metering needs already on Stripe for payments, while dedicated platforms like Lago, Metronome and Ordway offer more flexibility for complex pricing structures, with tradeoffs around implementation time and cost.

Why AI Startups Need Usage-Based Pricing

Traditional SaaS pricing assumes the cost to serve a customer stays flat regardless of how much they use the product. AI inference eliminates that assumption: every query pulls compute, model and infrastructure costs that scale with usage. The economics turn usage-based pricing into a financial necessity rather than a strategic preference.

Matching Your Model to AI Cost Structure

Before setting any usage price, you need to know your per-unit cost across at least three scenarios: cheapest model routing, current model mix and next-generation model costs. Your usage metric price should be margin-positive in the middle scenario. Some companies, including Intercom for resolutions and OpenAI for certain agent tasks, now price on outcomes like per-resolution or per-task-completed charges. This is typically the hardest model to implement. 

We see pricing as one of the most consequential decisions Series A founders make. If you're an early stage founder looking for a long-term pricing partner,  reach out to us to see if we'd be a good fit.

Frequently Asked Questions

What is the best pricing model for an early stage SaaS startup?

Hybrid pricing, which combines a base subscription with usage-based charges, is the most practical starting point for most early stage SaaS founders. It gives investors a predictable revenue floor while capturing expansion as customers grow. A base fee that covers your cost to serve, paired with usage charges on the features where consumption varies most, sets you up to layer in tiered or credit-based mechanics later if your buyer profile pushes you that way.

How does usage-based pricing affect Series A fundraising?

NRR becomes the lead signal because expansion is embedded in the model. You'll need to present cohort expansion charts rather than rely solely on formula-derived LTV figures, and you should clearly explain how much of ARR is committed versus usage-based or variable. Showing that strong NRR offsets lower GRR can be important.

Should AI startups use per-token pricing or credit-based pricing?

Per-token pricing works well for developer-facing API products where buyers are accustomed to granular consumption billing. Credit-based pricing works better when you have multiple action types with different cost profiles, because the credit abstraction layer lets you adjust underlying costs without changing headline prices. If your product bundles several AI capabilities into a single workflow, credits give you more pricing flexibility as model costs shift.

When should a startup switch from flat-rate to usage-based pricing?

A growing gap between what different customers cost you to serve and what they're paying is the strongest signal. If your heaviest users cost you noticeably more than your lightest users, but both pay the same monthly fee, flat-rate pricing is quietly eroding your margins. Having enough usage data to set tier boundaries confirms readiness.

‍