The Complete Guide to Software Pricing Models for SaaS Businesses

According to OpenView Partners' State of Usage-Based Pricing report, 61% of SaaS companies now use some form of usage-based pricing, 46% as a hybrid model and 15% as pure pay-as-you-go. A further 21% plan to test it. Most of the SaaS pricing guides in the top ten Google results still treat the choice as a marketing decision. We see it differently. Pricing is a software architecture decision, and the model picks the build. The build, not the price tag, is what most teams underestimate.

The model, metering, and migration triad

Every pricing decision lives in three layers, not one. The first is the model, what you charge for. The second is the metering layer, what you measure to charge for it. The third is the migration plan, how you re-price the install base when the model changes. Most teams ship the first layer and discover the other two only after the third or fourth pricing iteration.

We use the pricing-engineering triad, model, metering, migration, as the lens for every pricing engagement we run. The framework gives founders and CTOs the same vocabulary, which is the first thing that breaks down inside a growth team arguing about pricing.

Pick the value metric before the model. The value metric is the unit of customer success, messages sent for Slack, API calls for Twilio, tokens processed for OpenAI, contracts reviewed for Ironclad. Choose wrong and every later decision compounds the error. OpenView's annual SaaS Benchmarks Report found that teams reviewing pricing regularly grow noticeably faster than teams who do not. The follow-on detail rarely lands in those benchmark write-ups: every revision is a metering question and a migration question.

The rest of this guide is structured around the triad. Sections two through six cover the six pricing models against the engineering shape each one forces. Section seven covers the migration patterns we have run for clients moving from one model to the next. Section eight covers the build-versus-buy decision on the billing stack itself.

The tradeoff to keep in mind: every model that captures more revenue upside also demands more engineering rigour. Flat-rate is one webhook handler. Pure usage-based is a distributed-systems problem. The choice is rarely about pricing strategy alone, it is about what the team can ship and operate.

Flat-rate and per-seat pricing

Flat-rate and per-seat are the cheapest models to build and the fastest to outgrow. Both ship in a weekend with Stripe Subscriptions and a webhook handler. Finance loves them: predictable invoices, simple ASC 606 recognition, no metering reconciliation at the close.

Flat-rate works when the product has one job and one customer profile. Per-seat works when value scales with headcount, collaboration tools, CRM, design tools where each user is a real user. For founders on day one shipping an MVP, flat-rate is often the right answer. It removes a pricing question that does not yet matter and clears time for the things that do. Most of the MVP engineering we ship starts on flat-rate for exactly that reason.

The model breaks the moment value stops scaling with seats. Product-led teams discover this quickly. When per-user pricing punishes adoption, teams share logins to suppress the bill. The architectural gap is straightforward, your product instrumentation knows the customer is getting more value, but your billing model cannot see it.

The signal that per-seat is wrong: support tickets about shared accounts, expansion revenue stuck below 105% net revenue retention, and a sales team apologising for the price during competitive deals. The first two are observable in your data. The third is the one founders hear about last.

When does per-seat still make sense? Regulated industries where every user must be named for compliance. Internal tooling where seat count is the genuine value metric. Tools sold to IT departments who plan budgets by headcount. Per-user pricing versus usage-based pricing is rarely a clean swap, it is a strategic call about who the buyer is and how they procure.

Tiered pricing and the upgrade-path build

Tiered pricing is the default high-conversion model for self-serve SaaS. The Good-Better-Best frame has become the industry standard for a reason: it removes choice paralysis and creates a visible upgrade path. The catch is that every tier transition is an engineering decision finance teams rarely see until the support tickets start.

When to use tiered pricing in SaaS: any product where buyers cluster into three or four self-identifying segments, and where features can be cleanly fenced between tiers. The tier names matter less than the upgrade triggers. Starter, Growth, Scale read as progression. Basic, Pro, Enterprise read as procurement.

Four engineering surfaces carry the tier model. Each one is a separate build and a separate failure mode.

Most teams build the first two and skip the second two. They are quietly the most expensive to add later, because they touch billing data the team is no longer free to backfill.

The tier model also constrains your value-metric choice. If your customers' value scales smoothly (more API calls, more messages, more data), tiers create artificial cliffs. Buyers either over-buy at the next tier or stretch the lower tier past its limits and churn when they hit a hard cap. That is the signal a hybrid model would serve them better.

Usage-based pricing and the metering build

Usage-based pricing is the highest-NRR model in the public-comp data and the highest-engineering-cost model to ship. The OpenView numbers cited at the top of this guide put 61% of SaaS companies on some form of usage-based pricing. The headline obscures the build. The metering layer that real usage-based pricing requires is a distributed-systems problem, not a billing-system configuration.

Usage-based pricing implementation needs five layers working together: event ingestion, idempotency, deduplication, time-series aggregation, and an audit trail. Drop any one of them and revenue leaks or customer disputes follow.

Event ingestion is the front door. Your product emits an event every time the customer takes a billable action, an API call, a message sent, a token processed, a contract reviewed. The endpoint that receives those events must accept high throughput without dropping data. Most teams reach for the wrong tool here: a queue without idempotency, or a database with write contention at peak. API development engagements in this area typically end at a stream platform, Kafka, Kinesis, or an equivalent, with downstream consumers that handle the deduplication and aggregation.

Idempotency is the layer that protects you from retry storms. The same event can arrive twice when a network blip causes the client to retry. Bill the customer twice and they raise a dispute. Drop the event and you lose revenue. The fix is an idempotency key on every event and a deduplication step at ingest. This is a data engineering for usage analytics problem before it is a billing problem.

Time-series aggregation turns raw events into invoice lines. A million events become "Customer A: 12,400 API calls in March." The aggregation has to handle clock skew across distributed servers, late-arriving events, and corrections. Snowflake, BigQuery, and ClickHouse are common backends. The Stack Overflow Developer Survey 2024 results confirm those three as the dominant choices for engineering teams handling time-series workloads at scale.

What breaks first, in our experience: the audit trail. Most teams design metering for the happy path and forget that every invoice will eventually be disputed. The audit trail must trace every charge back to the raw events that produced it. Without it, customer support cannot resolve disputes and finance cannot pass an audit. We treat the audit trail as a first-class part of production-grade billing pipelines, not a feature to add later.

The economics force the buy decision for most teams. A custom in-house meter is roughly one engineering team for a quarter, plus indefinite maintenance. Metronome, Orb, m3ter, Lago, and Stigg sell purpose-built metering layers with audit trails included. The tradeoff is real flexibility versus build cost, section eight covers when each side wins.

Hybrid pricing and the architecture growth teams ship

Hybrid pricing is now the dominant architecture for public SaaS comps. The pattern is a committed base plus metered overage, Snowflake's commit-and-burn pricing, Twilio's platform fee plus per-message rate, Datadog's commit plus on-demand. The model gives finance the predictability of a subscription and gives product the upside of usage-based, without forcing a full metering-only migration on the install base.

Hybrid pricing model examples cluster around the same shape. A monthly or annual base fee covers the platform, the support, and a baseline volume of the metered metric. Overage above the baseline is billed at a per-unit rate. Some hybrids add a third tier, committed-use discounts where the customer pre-buys a large block of usage at a lower per-unit rate in exchange for a longer commitment.

The rating engine carries the complexity. Three pieces have to work in concert: commit drawdown logic (how much of the baseline the customer has used this period), overage thresholds (when the per-unit rate kicks in), and true-up cycles (when commits and overages reconcile against the contract). Each piece is a small algorithm. Together they are a system, and the system has to be auditable from raw event to invoice.

The hybrid model also smooths a migration. Teams moving from per-seat to usage-based can introduce the metered component as overage on top of the existing seat fee, run both meters for a quarter, and only flip to a usage-led structure once the data confirms the pricing curve holds. That is the safest migration we run for clients who cannot afford a revenue dip during the cutover.

The signal hybrid is the right answer: variable customer usage, sales-led enterprise contracts, and a finance team that needs forecastable ARR. The signal it is wrong: a self-serve product where the base fee creates an entry barrier the metered model would not.

Outcome-based pricing and the AI-era shift

Outcome-based pricing is the structural answer to AI agents that produce work instead of providing access. Per ticket resolved, per lead qualified, per contract reviewed, per refund processed. The model aligns vendor revenue with customer outcome more cleanly than any other. The measurement problem is harder than the metering problem in usage-based.

The economic context is well established. According to a16z's LLMflation analysis, LLM inference costs are dropping by roughly 10x per year at a fixed quality tier. The cost of running an equivalent model has fallen by a factor of 1,000 in three years. When the input cost collapses but the output value does not, the seat model loses its grip. A seat does not represent the work an AI agent does, the work itself does.

Intercom's Fin agent charges per resolution. Zendesk's AI sells the same shape. Other AI products still ship seat-based pricing, GitHub Copilot among them. The split is not yet settled. The teams running AI development engagements for our clients increasingly model both paths, because the right answer depends on whether the agent replaces a human or augments one.

The hard engineering question is attribution. What counts as a resolved ticket? If the customer reopens the ticket two days later, does the resolution still count? If the agent escalates to a human, is the charge for the resolution or the attempt? Each rule is a product decision and a billing decision at once. The dispute surface is wider than in pure usage-based, because customers can argue the outcome itself, not just the count.

Outcome-based pricing also still has unresolved revenue-recognition questions under ASC 606. Performance obligations are clearer in subscription and usage models. Outcome models introduce measurement uncertainty that auditors will probe. We tell clients to bring their revenue-recognition accountant into the pricing conversation before the model ships, not after.

The pricing migration problem

The single most expensive moment in any SaaS pricing strategy is the moment you change it. The engineering shape of the migration determines whether NRR survives the cutover. We have run three patterns for clients migrating from per-seat to usage-based or to hybrid. Each pattern carries a different risk profile.

Repricing existing SaaS customers is not a single decision. It is a sequence of small ones. Migrating from per-seat to usage-based pricing without churning customers usually means grandfathering the largest accounts on their current rate for twelve to eighteen months, while new customers come in on the new model. The grandfathered base pays for the migration build.

Shadow billing is the diagnostic step we recommend before any migration commits. Run the new model against the last ninety days of usage data. Compare the modelled bill to the actual bill. The deltas reveal the model's blind spots, which customer cohorts pay more, which pay less, which see no change. Most teams discover at this step that their pricing intuition was off by 20% or more for a few customer segments. Fix it before the cutover and the migration ships clean. Platform modernisation work we have run for clients almost always starts with a shadow-billing exercise.

The customer-comms layer matters as much as the engineering layer. A migration that lands well technically can still destroy trust if customers feel ambushed by a new bill. The pattern that works: forty-five days of notice, an in-product calculator showing the customer what they would pay under both models, and a named account contact for any customer above a defined revenue threshold. That last detail is what protects the top of the install base.

Build versus buy on the billing stack

Most teams should buy billing infrastructure and build the metering layer in front. The instinct at seed and Series A is the inverse, build it all, because it feels cheaper. The instinct is usually wrong. The build cost of a billing system is rarely the headline number; the maintenance cost over eighteen months is.

In-house metering becomes non-negotiable in a few cases. High event volumes where the per-event cost of a managed platform exceeds the engineering cost of a custom meter. Sub-second rating requirements where the network round-trip to an external service is too slow. Regulated industries where on-premises constraints rule out a cloud billing vendor.

For everyone else, the buy-the-billing-stack pattern wins on time-to-value and total cost of ownership. The right shape is usually a managed billing platform underneath, a thin custom metering layer in front to handle product-specific events, and a clear interface between the two. We typically scope this engagement under the dedicated team model, or as staff augmentation when the in-house team owns most of the work but needs a senior pair on the metering layer specifically.

The mistake we see often: teams who buy a metering platform but never invest the engineering hours to instrument the product properly. The platform is only as accurate as the events it receives. Bad instrumentation produces bad invoices, which produces customer disputes. Most metering implementations fail at the product side, not the platform side.

Frequently asked questions about SaaS pricing models

Usage-based versus consumption-based pricing: what's the difference?

They are the same model under two names. Usage-based pricing is the term OpenView, Bessemer, and most product teams use. Consumption-based pricing is the term enterprise sales teams and cloud vendors prefer. AWS, Snowflake, and most of the data-platform vendors call their model consumption-based; Twilio, Stripe, and most of the API-platform vendors call theirs usage-based. The naming history matters less than the underlying shape. Both charge by what the customer uses. Both need the same metering infrastructure. When evaluating vendors and reading benchmarks, the two terms are interchangeable.

How often should a SaaS company review pricing?

Most teams who review pricing quarterly outperform teams who treat pricing as a static decision, according to OpenView's annual SaaS Benchmarks Report. The right cadence depends on the stage. Seed-stage products should expect to change pricing every six months as the value proposition sharpens. Series A and B products typically settle on a quarterly review and an annual change, with the review focused on cohort performance and the change reserved for material shifts in the product or market. Enterprise SaaS reviews pricing on contract renewal cycles, with annual list-price changes timed to the broader sales-planning calendar.

When does per-seat pricing still make sense?

Per-seat pricing still makes sense when seat count is the genuine value metric. Three product types fit cleanly. Collaboration tools where each user is an active participant, design tools, project management, communication platforms. Regulated industries where every user must be named for compliance, healthcare records, financial systems, audit-trail-driven tools. Internal-tooling buyers who plan budgets by headcount and procure software the same way. Outside those three patterns, per-seat usually undersells the product to high-usage customers and overcharges the low-usage ones. The signal it is wrong: shared logins, expansion revenue stuck low, and a sales team apologising for the price.

How do you migrate without churning customers?

Grandfather the largest accounts. Run shadow billing for ninety days against real usage data before the cutover. Give forty-five days of notice. Build an in-product calculator showing the customer their bill under both models. Assign a named account contact for any customer above a defined revenue threshold. The migration is rarely a single cutover, it is a sequence of cohort moves over twelve to eighteen months. New customers come in on the new model from day one; existing customers move on their renewal cycle, with the largest cohort moving last. Section seven covers the three migration patterns in more detail.

Is a billing platform required for usage-based pricing?

No, but the build cost of doing it in-house is roughly one engineering team for a quarter, plus ongoing maintenance. Metronome, Orb, m3ter, Lago, and Stigg sell purpose-built metering and rating layers with audit trails included. Stripe Billing covers the lighter end. The tradeoff: a managed platform handles ingest, deduplication, aggregation, and rating, but constrains you to its data model. A custom build gives full flexibility, but the maintenance burden grows with every new pricing variant. Most teams under 100 million ARR are better off buying the platform and building only the product-side instrumentation. Section eight covers the comparison in detail.

How does ASC 606 affect usage-based pricing?

ASC 606 governs how SaaS companies recognise revenue. Subscription models are straightforward, revenue recognises ratably over the contract period. Usage-based models recognise revenue as the customer consumes the service, which means month-to-month variation that finance teams have to forecast carefully. Outcome-based models introduce a harder question: when is the performance obligation satisfied? Per-resolution pricing recognises on the resolution; per-outcome pricing on the outcome. Auditors will probe the measurement methodology. Bring your revenue-recognition accountant into the pricing conversation before the model ships. The cost of getting ASC 606 wrong after launch is much higher than the cost of getting it right before.

The build-versus-buy question on the metering layer is the one most teams answer late. Picking the pricing model is the easy decision. Building the meter that supports it, designing the migration plan when growth changes the answer, and operating the rating engine through pricing iterations is the work that determines whether the strategy holds.

Tech Kodainya's software development service is built around that work. We ship the metering pipelines, rating engines, and migration tooling that sit behind production SaaS pricing, senior engineers, your stack, your timeline, with the audit trail and the proration math already in place. Engagements start within two weeks of the first call.

Ready to build the metering layer behind your pricing model? Talk to the software engineering teams we run.