How to choose the right pricing model for your business, the six factors that decide it

Start with one fast filter from a16z's rule of thumb, because it gets you most of the way in a sentence: usage-based pricing fits products whose end user is other software, and subscription fits products whose end user is a human. 

Software-to-software usage, like API calls, code tests, or data transfer, can grow exponentially and ships with clean telemetry you can meter. A person can only watch so many training videos, and nobody wants to be nickel-and-dimed. As the a16z partners point out, imagine a CRM that charged a rep every time they created an opportunity.

That filter points you at an answer. The six factors below tell you how confident to be in it, and where I'd call a hybrid the honest answer. Score your product against each one. (Weighing more than these two? Our guide to SaaS pricing models maps all seven.)

1. Does value scale with usage, or stay flat?

Price on usage when a customer gets more value every time they do more, and price on access when the value holds steady once they're set up. 

A gym charges the same whether you show up three times or thirty. An electricity bill tracks every unit you burn. Software splits the same way: a16z's read is that software-to-human products make people more productive with a natural ceiling on consumption, while software-to-software products power a customer's own systems and scale without one.

Here's what to look at:

• Does one more API call, workflow, or generated document create more value for the customer, or just more activity?

• Six months in, do your heavy users clearly get more out of the product than your light users?

• Is there a natural ceiling on how much any one customer can consume?

The signal: value that climbs with activity points to usage, and value that plateaus after onboarding points to subscription.

2. Is there one clean value metric you can actually meter?

Usage-based pricing only works if you can name a single unit that tracks value and measure it reliably, and if you can't, subscription is the more honest structure. A value metric is the unit you charge on, the thing a customer would point to and say "that's what I'm buying." 

Kyle Poyar's criteria for a good one are worth keeping on a sticky note. It should correlate with the value different customers see, share in their success without discouraging adoption, let customers start small and scale, rise month over month for the average account, and stay feasible to meter in your product. 

Snowflake adds that it should be concise, easy for a customer to understand, and matched to your delivery cost. If you're pricing an AI product, our breakdown of pricing metrics that capture AI product value goes deeper on choosing one.

Finding one is harder than it looks. Poyar's example is an online survey tool: charge per survey and you make the customer stop and decide every time someone wants to launch one, but charge per response and a response from a paying B2B customer is worth nothing like one from a free user or your own employee. 

When no single unit is honest, the answer is usually to mix a subscription package with a usage fee rather than force a bad metric.

Here's what to look at:

• Can you name the one unit a customer would agree represents the value they get?

• Does that unit go up for the customers you keep and down for the ones who churn?

• Can you meter it accurately in real time, without confusing customers or inviting gaming?

The signal: a clean, meterable unit that tracks value points to usage, and no single honest unit points to subscription or hybrid.

3. Does your cost to serve rise with usage?

When serving a customer gets more expensive as they use more, usage-based pricing protects your unit economics, and flat pricing quietly erodes them. 

This is the factor AI teams feel most sharply, because a generative AI product pays model and compute costs (its cost of goods sold, or COGS, what it costs to serve one customer) that move directly with token volume. 

a16z frames the trap plainly: run an infrastructure company on a flat subscription, watch a customer's usage skyrocket, and suddenly you're losing money to serve your most active account. Watching that spend is its own discipline, and our roundup of tools for managing AI inference costs covers where the money goes.

Here's what to look at:

• Does your gross margin shrink when a customer doubles their usage?

• Do you pay a cloud, model, or infrastructure bill that scales with what your customers do, like tokens, compute, or storage?

The signal: a cost to serve that rises with usage points to usage-based pricing, and near-zero marginal cost means flat pricing is safe.

4. Can customers predict what they'll spend?

Usage-based pricing wins on fairness and loses on predictability, and lost predictability is what stalls deals. Bill shock is not a rare edge case, most IT leaders hit unexpected charges last year, and a majority cut projects over surprise software costs. 

a16z now runs a whole follow-up post on helping customers predict usage-based spend, which tells you how real the problem is. If you're unsure, it's worth learning how to test usage-based pricing before you fully commit.

Here's what to look at:

• Could a customer estimate next month's bill within a range they'd sign off on?

• Does usage spike unpredictably, or follow a steady monthly pattern?

• Do you have caps, alerts, and a usage dashboard to prevent bill shock before it lands?

The signal: predictable, forecastable usage means either model works and finance will prefer subscription, while volatile usage points to usage-based only if you can bolt on the tools that make spend predictable.

5. How does your buyer want to spend?

The mechanics can favor usage while your buyer still wants a fixed number, and the buyer usually wins that argument. 

The average enterprise runs over 100 SaaS apps, and no user wants to babysit a meter on each one. Finance-led buyers want a number approved once and left alone. 

A CFO signing a $50,000 annual contract knows exactly what the year costs, and some will pay a premium for that certainty. Technical buyers are the opposite, and they resent paying for capacity they never touch. If your buyers skew enterprise, our guide to enterprise billing software covers what procurement will expect.

Here's what to look at:

• Who signs, a CFO who plans budgets a year out, or an engineer optimizing spend?

• Does procurement require a fixed contract number to approve the deal?

• Would charging per action make users hesitate before they use the product?

The signal: a certainty-first buyer points to subscription, or to a usage model with a committed floor, while an efficiency-minded technical buyer points to usage.

6. How do accounts grow?

Look at how your best accounts expanded six months in, because that pattern picks the model better than any theory. Accounts grow in one of three ways. 

Horizontal growth adds teammates, so value rises with participation and you price per seat. Vertical growth runs more workload on the same headcount, so two identical teams can generate very different values and you price on volume. Dual growth does both, which is the textbook case for a hybrid.

The data behind vertical growth is hard to argue with. Across 2026 SaaS benchmarks compiled by Bessemer, KeyBanc, and OpenView, usage-based and hybrid models post 115% to 130% net dollar retention (the share of revenue you keep and expand from existing customers), against 95% to 105% for flat subscription. 

Because usage revenue expands on its own as customers consume more. Seven of the nine best-net-retention SaaS IPOs of recent years, including Slack, Snowflake, and Elastic, ran usage-based models. 

That expansion advantage is a big part of why AI companies have adopted usage-based pricing. Poyar's caution is worth holding alongside that: usage revenue behaves like compound interest, slower to your first million and faster later, so it rewards patience. 

New Relic said it well when it moved to consumption:

"A consumption model changes the fundamental nature of the relationship between the vendor and the customer; if we don't build great products that customers enjoy using, we won't get paid." - New Relic investor letter

Here's what to look at:

• Did your best accounts add teammates, run more workload, or both, in their first six months?

• Do those accounts expand on their own as they succeed, or only when a rep pushes an upsell?

The signal: growth by participation points to subscription, growth by workload points to usage, and both at once points to hybrid.

Run all six and a pattern almost always shows up, at least it does every time we do this exercise with a team. Most products lean clearly one way. Real conflict is itself the answer: if value scales with usage but your buyer needs certainty, or your cost to serve climbs but usage is spiky, that tension is exactly what a hybrid resolves. 

And keep a16z's caveat in view, none of this is a hard-and-fast rule, pricing is a spectrum, and the six factors tell you where on it you belong.

The infrastructure question most teams skip

Before you commit to usage-based pricing, answer one hard question: can you meter what customers use, accurately and in real time? If you can't, the model will hurt you no matter how well it fits on paper.

Usage-based billing needs more than a payment gateway. You need real-time metering that aggregates events reliably, rolling thousands of raw events into one correct total, plus pricing logic for tiers, minimums, and overages, and usage breakdowns a customer can actually check. 

Idempotency matters more than it sounds: if the same event arrives twice because a network or SDK retried, the system has to count it once, or every retry becomes a double charge on your customer's invoice. 

When Nikhil, our CTO, was solving event pipelines at Zomato's scale, that deduplication problem wasn't theoretical, it was the line between a correct bill and an angry one.

Miss this foundation and usage-based pricing turns into operational chaos, and we watch it break more teams than any other factor on this list. 

Simplismart reclaimed 30% of daily engineering bandwidth and scaled to 750+ pricing features after moving billing to Flexprice, instead of running metering as a second product. If you can't meter accurately yet, subscription is the honest call until your infrastructure catches up.

Why most teams end up hybrid

Most teams we talk to don't pick one, they run both. A hybrid pricing model pairs a subscription base with usage on top, so customers get a predictable floor while your revenue still grows with what they use. 

A customer might pay $50 a month for platform access and a set allotment of credits, then a few cents for every credit beyond it. In OpenView's 2023 State of Usage-Based Pricing report, 46% of SaaS companies already ran some hybrid. 

It's the model OpenAI, Snowflake, and Twilio converged on, because it gives the seller predictability and the buyer fairness at the same time. Around 80% of customers say usage-based pricing matches the value they get, per Zuora, and hybrid keeps that alignment without giving up a stable base. For a product that outgrew one model, hybrid is usually the honest answer.

Launch your pricing model without locking in

Founders rarely get burned by picking the wrong model. They get burned by locking into billing infrastructure that makes switching painful. 

That's why we built Flexprice to keep pricing logic separate from billing plumbing. It's open source and self-hostable, so you can inspect it, run it on your own infrastructure, and change your mind later without a migration.

Launching a usage-based model takes four steps:

1. Define your usage metric in Pricing Models: API calls, tokens, events, seconds, whatever maps to value.

2. Instrument your usage events once and let Usage Metering track them in real time.

3. Configure meters and rate cards for usage, subscription, or a hybrid of both, with Credits and Wallets if you sell prepaid credits.

4. Let Billing and Invoicing aggregate the usage and invoice at the end of the cycle.

You don't hard-code prices into product logic or build a custom invoicing pipeline, and you're not rebuilding billing six months later when you want to test something new. Spend your time deciding how customers should experience value, and try Flexprice free when you're ready to build it.