Usage-based pricing is now the default starting model for new SaaS products. That shift is not the story. The story is what it demands underneath: a metering layer that most teams have never built, do not have on their roadmap, and will need to rebuild from scratch at exactly the wrong moment.
I have been watching this play out since 2016. Here is what I have learned.
The world that is ending
For most of SaaS history, the pricing conversation was simple. You negotiated a contract. You agreed on a number of seats, or a fixed quantity of something, often upfront for an annual term. The product did not need to know how much each customer consumed. The invoice was predetermined.
When usage-based pricing entered the conversation for older products, it arrived as a retrofit. Companies moved toward it when marketplace listings demanded it, because AWS Marketplace and GCP Marketplace ran on hourly-based pricing and vendors had to adapt. Or they moved toward it under competitive pressure, tacking a consumption component onto an existing subscription model. The metering layer was added later, because the pricing model demanded it later.
That sequence — build first, meter when necessary — is the sequence that creates the problem.
I saw this at Instana in 2016
Instana, the application performance monitoring company I joined as Director of Product-Led Growth and which IBM acquired in 2020, was born in 2015 on a model called SIMs: Sensor Instance Minutes. Every monitored process, every minute, was a unit. Fully usage-based from day one.
It was a decade ahead of the market. Not because the idea was wrong. Because customers were not ready, and the sales team pushed back hard. The VP of Sales made the same argument you still hear today: usage-based pricing creates revenue unpredictability. We know what a seat costs. We do not know what a minute of monitoring costs at scale. Predictability matters to the sales team’s forecast.
That argument was valid in 2016. The market was per-seat. Customers bought annual contracts. Asking them to reason about per-minute consumption was friction they did not want.
What has changed is not that vendors got braver. It is that AI made the argument irrelevant.
Why AI ended the vendor-choice era
When your product has a meaningful AI component, your cost per customer is no longer fixed. A customer using your AI features heavily costs you ten times what a light user costs. Flat annual pricing in that context does not just misalign price with value. It creates a structural subsidy problem: your lightest customers fund your heaviest ones. As the AI component grows, that subsidy becomes unsustainable.
The economics of AI-powered software are fundamentally incompatible with the per-seat model. That is not a framing. It is arithmetic.
So vendors face a genuine choice: adapt the pricing model to consumption, or watch the model break as AI usage scales. The “revenue unpredictability” objection does not go away, but it becomes the smaller problem. The larger problem is that flat pricing on variable-cost products produces the wrong revenue at the wrong time from the wrong customers.
What reinforces this pressure from the buyer side: enterprise procurement teams have spent years paying for shelfware — seats assigned to 500 people when 80 actually used the product. They are done with that model. Reliance on seats as the only value metric has collapsed to 8% of the SaaS market (OpenView, 2025). Nearly 50% of companies that adopted usage-based pricing did so in the last two years alone (Monetization Monitor, 2025). The adoption is accelerating because the conditions that made per-seat sensible have disappeared.
The bottleneck nobody talks about
Here is the practical problem that becomes visible when a company decides to move to usage-based pricing: they discover they have no metering.
Not incomplete metering. No metering. The product was never instrumented to track consumption at the granularity required. They know customers logged in. Also know which plan customers are on. They do not know how many API calls each customer made last month, which features they used most, or what the unit economics look like by customer segment.
Rebuilding that instrumentation into a live product with paying customers is expensive, slow, and disruptive. Metronome, one of the leading billing infrastructure companies, estimates that building robust metering infrastructure from scratch takes three to six months of engineering work — at exactly the moment when the team should be focused on product and growth. That is three to six months spent on billing plumbing while competitors ship features.
The companies that avoid this are the ones that treated metering as a first-class product concern from the start. Not a billing feature. Not a finance team concern. A product architecture decision made before the first customer signs.
98% of SaaS companies modify their pricing at least annually, yet 55% report their billing systems cannot efficiently accommodate those changes (Chargebee, State of Subscriptions Report, 2025). That gap does not come from indecision about pricing models. It comes from never building the infrastructure that makes pricing models changeable.
The Chargebee signal and the OpenMeter signal
At Akamas, the AI performance optimization company where I served as COO, we needed to introduce subscription management and granular metering as we moved toward usage-based pricing. We evaluated the vendors in this space carefully.
Chargebee came up early. It is a well-established subscription management platform, the kind of tool that has served the SaaS billing world well for a decade. What we found during evaluation was that metering had been added to Chargebee as a catch-up feature: the market was asking for it, and they were responding. The metering capability existed, but it had been bolted on to an architecture designed for subscriptions, not built around consumption as the primary primitive.
OpenMeter was different. It was designed from the ground up around metering as the core concept: the assumption that you need to track consumption precisely, in real time, before you can bill for anything. We chose OpenMeter.
The industry validated that decision in September 2025. Kong, the API gateway company, acquired OpenMeter, the developer of an open-source platform for usage-based metering and billing. Kong’s rationale was direct: in the AI era, billing is no longer a traditional subscription challenge but a metering problem. AI agents can trigger thousands of API and data calls per second, demanding scalable, precise billing systems that operate at machine-driven speed.
Kong did not acquire a billing feature. It acquired metering infrastructure and treated it at the same layer as API routing and security. That is the signal. Metering is not a billing add-on. It is foundational.
Dash0: the same team, doing it right from day zero
The clearest proof of where the market has arrived comes from Dash0.
Founded in 2023 by Mirko Novakovic and the team behind Instana, Dash0 is an AI-native observability platform. The same people who built Instana — who lived through the SIM pricing vision in 2015 and 2016 when the market was not ready — started over in 2023 and made a different set of decisions.
They went usage-based from day zero. Dash0’s pricing is based on telemetry volume rather than users, GB, or ingestion volume, and includes cost controls, monthly budget limits, and full cost visibility built directly into the platform (Dash0, 2025). The metering layer was not an afterthought added when the pricing model changed. It was the architecture the product was built on.
The market’s response: 600 customers in under two years, a $35M Series A led by Accel and Cherry Ventures in October 2025, and a $110M Series B led by Balderton Capital in March 2026 — reaching unicorn status inside three years.
The Instana team had the right idea in 2016. The market had not caught up yet. By 2023, it had.
What is happening to the SaaS products that did not adapt
The pressure on incumbents is real and documented. Klarna built its own AI-native CRM and dropped Salesforce, saving approximately $40 million annually on contract labour and tooling. Blavity, a digital media group, has already decided not to renew its Salesforce contract when it expires in early 2027, expecting savings of 50% to 60% from switching to AI-built tooling.
These are not isolated decisions. They represent a structural shift in what enterprise buyers expect from software. A Salesforce Enterprise contract costs $9,600 per year for ten users. Teams are now building custom tooling with AI that does exactly what they need for a fraction of that cost. The monolithic SaaS product that justified its price with breadth of features is under direct pressure from narrow, AI-built alternatives.
The SaaS products that will survive this are the ones that can price correctly for actual consumption, expand revenue as customers grow, and contract it fairly when customers shrink. That requires knowing exactly what customers consume. That requires metering.
What granular actually means now
The granularity of metering is compressing fast. Hourly usage metering sounded advanced a few years ago. The market is moving toward minute-level and event-level metering, particularly for AI workloads where inference costs spike and drop within a single session.
The distinction that most writing on this topic misses: the internal cost metric and the customer-facing value metric are not the same thing, and confusing them is expensive.
Your infrastructure costs are denominated in compute seconds and API calls. Your customers measure value in transcriptions completed, queries answered, or support tickets resolved. Good metering translates between the two: you track infrastructure cost precisely internally, and you expose the value metric to the customer.
Charging customers per CPU-second is technically precise and commercially useless. It forces the customer to reason about your infrastructure instead of their outcomes. The defining rule: the value metric should reflect how customers extract value, not your internal infrastructure cost. A video transcription service should charge per completed transcription, not per CPU-second, even though CPU-seconds is what the vendor actually pays. Customers buy outcomes; vendors buy infrastructure.
Getting this right requires instrumenting the product at the level of customer-facing actions, not just infrastructure events. That is a product decision, made in the architecture, not a billing configuration made at contract time.
Three questions worth asking before this becomes urgent
Can you answer, today, how much each customer consumed last month? Not approximately. Not by pulling a database query that takes two days to write. In a dashboard, in under a minute, broken down by customer. If you cannot, you are not ready for usage-based pricing, and the retrofit will hurt.
Is your value metric defensible as AI scales? Per-seat pricing made sense when humans were the users. When AI agents can do the work of ten users, per-seat becomes a ceiling on your revenue. The right value metric scales with what the customer actually accomplishes. If a customer gets ten times more value from your product next year, your revenue from that customer should reflect it.
Is metering on your product roadmap, or only on your pricing page? Usage-based pricing listed on a pricing page is marketing. Metering infrastructure built into the product is architecture. The first is reversible. The second is what makes everything that follows possible: accurate billing, usage-based expansion, product-qualified lead detection, cost forecasting for customers. All of it depends on the same foundation.
The connection to PLG
Product-led growth depends on product signals. You cannot identify a product-qualified lead without knowing what that user has done inside the product. Nor trigger an expansion motion without knowing that a team has hit a usage threshold. You cannot optimize your activation flow without knowing where customers drop off.
Metering at the level required for usage-based pricing is the same infrastructure that makes PLG operational. They are not separate concerns. A product that knows exactly what every customer consumes, in real time, is a product that can run a PLG motion, price correctly, and identify expansion opportunities without a sales team asking. A product without that instrumentation is flying blind on all three.
FAQs
Usage-based pricing is a model where customers pay based on how much they actually consume rather than a fixed monthly or annual fee. The unit of consumption varies: API calls, data ingested, tasks completed, AI queries processed, or minutes of usage. The model aligns cost with value and allows revenue to expand naturally as customers grow, without requiring contract renegotiation.
Metering is the product infrastructure that tracks how customers consume a product in real time, at the granularity required to price and bill accurately. Without metering, usage-based pricing is not operationally possible. Building metering into a live product after launch takes three to six months of engineering work and creates technical debt that constrains future pricing changes. Building it from the start is a product architecture decision, not a billing one.
A subscription charges a fixed fee regardless of how much the customer uses the product. Usage-based pricing charges for actual consumption. Most modern SaaS products use a hybrid model: a base subscription that covers access, combined with a usage component that captures expansion as consumption grows. The hybrid avoids bill shock for customers while preserving the expansion economics of consumption pricing.
Per-seat pricing as the only pricing dimension has collapsed to 8% of the SaaS market (OpenView, 2025). More than 80% of SaaS companies still include a seat component as part of a hybrid model, but relying on seats alone is no longer viable when AI agents can do the work of multiple users and when enterprise buyers have spent years paying for unused seats. The direction is clear: usage and outcome-based components are growing as the primary revenue drivers.
Kong, the API gateway company, acquired OpenMeter, an open-source usage metering and billing platform, in September 2025. The acquisition was driven by the recognition that in the AI era, billing has become a metering problem. AI agents trigger thousands of API calls per second, requiring infrastructure that can track and price that consumption precisely in real time. Kong integrated OpenMeter into its Konnect platform to treat metering as foundational infrastructure, at the same layer as API routing and security.