.png)
.jpg)
Frameworks, core principles and top case studies for SaaS pricing, learnt and refined over 28+ years of SaaS-monetization experience.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
“Do you really think usage-based will work? Nobody will do it. They can’t find anything on the dashboard. They don’t understand what’s going on.”
That skepticism is more common than most pricing teams want to admit. And it’s not because usage-based pricing (UBP) is inherently flawed. It’s because most companies try to price on usage without first building the systems that make usage legible, trustworthy, and operationally manageable.
In a recent Monetization Engineering Podcast conversation, Akhil Gupta, COO/CTO of Monetizely, spoke with Lior Mechlovich (ex-AWS, former CTO/co-founder of Amberflow, now CTO at Salespeak.ai) about why billing isn’t “solved,” why metering is the real bottleneck, and why most SaaS companies accidentally build a monetization stack that can’t survive the AI era.
Here’s the punchline:
Usage-based pricing fails when customers feel surprised, confused, or powerless.
The fix is not a new price metric. The fix is a monetization architecture.
The Old SaaS World Was Simple (Because Marginal Cost Was Basically Zero)
For the last decade, SaaS monetization was almost comically straightforward.
You priced per seat per month. You sold a contract. You invoiced. You moved on.
Why did that work? Because for most “classic SaaS,” the cost to serve one more user was close to zero. If you had 500 users, adding the 501st didn’t meaningfully change your unit economics. The pricing model didn’t have to be perfect. It just had to be consistent.
That world is gone.
If you’re building AI-powered products, every meaningful user interaction now has real variable cost: tokens, inference compute, API calls, model routing, vector searches, tool calls. The marginal cost is no longer negligible.
And that flips a dangerous dynamic:
Your most engaged customer can become your least profitable customer.
If you don’t redesign your monetization system, “growth” can literally deepen your losses.
The Myth: “Billing Is Solved. Just Plug In Stripe.”
A lot of teams believe billing is a solved problem because Stripe exists.
This is where Lior’s perspective was refreshingly blunt. Stripe is great at billing for subscriptions and simple invoicing. But the minute you introduce usage, limits, credits, exceptions, thresholds, or workflows, you fall off a cliff.
Here’s a simple sequence that breaks the “Stripe solves billing” illusion:
- You add a cap: “Up to 100 conversations”
- Now you need alerts: “Email me at 80%”
- Now you need controls: “Block at 100% or keep running?”
- Now you need exceptions: “Don’t bill spam or internal test usage”
- Now you need corrections: “We marked that usage late, re-rate it”
- Now you need visibility: “Show me usage in near real time”
- Now you need workflows: “Notify AE, update Salesforce, trigger upsell motion”
None of that is “billing” in the narrow sense.
It’s monetization operations. It’s product experience. It’s auditability. It’s cross-functional workflow design.
And it’s exactly why customers say, “I don’t understand what’s going on,” and then churn or revolt.
The Real Problem: Metering Is the Foundation, and Most Companies Don’t Have It
If there’s one idea that came through clearly: metering is the root system.
Most companies talk about “usage-based pricing” as if the hard part is choosing the metric: API calls, tokens, seats, workflows, accounts, etc.
But the hard part is everything underneath:
- collecting usage events reliably
- attributing them to the right tenant/customer
- deduplicating and preventing double counting
- handling failures without losing or duplicating usage
- supporting different kinds of meters (count, max per day, distinct users per month)
- making usage auditable and replayable
- exposing usage data to customers and internal teams
- applying pricing logic downstream without rebuilding instrumentation
Lior put it simply: in AWS, the infrastructure is decoupled. Metering exists as its own capability, separate from billing. That separation is not philosophical. It’s practical.
Because metering is for facts and billing is for money.
Facts need to be captured at scale, with tolerance for analytics imperfections at times.
Money needs to be exact, auditable, and reversible when something breaks.
Treating these as the same system is how you end up with a fragile mess.
Why “Metering First” Matters: Pricing Changes Faster Than Engineering
Pricing is not owned solely by engineering. In fact, pricing shouldn’t be blocked by engineering.
In a healthy organization, pricing evolves as you learn:
- which customers get value from which features
- where costs are spiking
- where usage correlates (or doesn’t) with willingness to pay
- how to build tiering and fences without creating customer backlash
- how to add new dimensions (region, model type, plan type, workflows)
If your metering system is tightly coupled to your billing logic, every pricing experiment becomes an engineering migration.
That kills agility.
The “metering first” approach creates a clean separation:
- Capture usage events with rich dimensions (the factual layer)
- Aggregate, analyze, and model (the decision layer)
- Apply pricing logic for billing (the monetization layer)
When pricing changes, you change the pricing logic, not the instrumentation.
That’s what makes the business nimble without turning engineering into a bottleneck.
Why Metering Is Harder Than It Looks (Even If You’re “Just Counting”)
A non-technical executive might assume metering is “just add a row” or “increment a counter.”
In practice, it’s full of nasty edge cases that only show up at scale:
- Exactly-once counting: An API call retries. Did you count it twice?
- Failure recovery: A pipeline drops events. Can you replay safely?
- Distinct meters: “Unique active users per month” requires dedup logic.
- Max meters: “Peak storage per day” requires tracking peaks over windows.
- Stateful meters: An instance starts/stops/restarts; you bill lifetime duration.
- Dimensions: Region, plan, feature flags, customer segments, model types.
- Auditability: Finance wants to verify “why did this customer get billed X?”
And once you add enterprise realities, it gets worse:
- discounts by dimension
- commitments and true-ups
- contract overrides
- multi-product bundling
- marketplace billing (AWS Marketplace, etc.)
This is why companies end up with 10s of engineers working on monetization infrastructure and still feel behind.
The Breaking Point at $10M+ ARR: It’s Not Just Billing, It’s “Data Democracy”
One of the best insights from Lior was what breaks after you’ve solved the obvious early-stage issues.
At roughly $10M ARR and scaling fast, two things tend to force a reckoning:
1) Usage data is trapped in silos
Sales teams don’t know who is consuming value.
CS doesn’t have reliable signals for adoption or risk.
Finance can’t reconcile usage with invoices confidently.
Engineering can’t answer “what’s driving cost” quickly.
The result is slow decision-making and reactive firefighting.
2) The business wants new monetization motions
You want to introduce a new pricing model.
You want to add usage components to tiers.
You want enterprise constructs (commitments, dimension-based discounts).
You want marketplace support.
But your existing system can’t evolve without painful rewrites.
This is when “we’ll fix it later” turns into “we can’t ship the business model we need.”
Who Owns the Integration Layer?
This is where monetization becomes a true cross-functional discipline.
Usage data touches:
- Engineering (instrumentation)
- Product (what is billable, what is visible)
- RevOps (CRM, CPQ, quoting workflows)
- Finance (invoicing, rev rec, audit)
- Sales/CS (alerts, expansions, renewals, adoption)
So the “glue layer” rarely has a single owner. What tends to work is a cross-functional ownership model:
- a platform/internal tools team (to build/maintain the pipeline)
- a business application owner (CRM/CPQ/billing systems)
- finance partnership (controls/auditability)
- product input (customer-facing UX + fairness rules)
If that sounds heavy, it is.
But the alternative is worse: scattered ownership, inconsistent definitions of usage, and a customer experience that feels like a black box.
The Real Test of Usage-Based Pricing Is Trust
Usage-based pricing doesn’t fail because customers hate usage.
It fails because customers hate surprise.
Customers will accept variable bills if:
- they can see usage clearly
- they understand what drives it
- they can predict it
- they can control it
- they trust you won’t miscount or mischarge
That requires more than a pricing page.
It requires a monetization stack that treats usage as a first-class product experience.
So if your team is asking, “Will usage-based work for us?” the better question is:
Do we have the metering, visibility, workflows, and auditability to make usage feel fair and predictable?
Because in the AI era, you don’t get to choose whether costs are variable.
You only get to choose whether your monetization system is engineered to handle reality.
If you want, I can turn this into a tighter “Monetization Engineering playbook” format (with a simple reference architecture: entitlements → metering → pricing logic → billing → rev rec + dashboards + alerts) and make it publish-ready for your blog.