Usage Based Pricing in SaaS: Why We Did It (And What We Learned)

Furthermore, when we launched self-service at Viewabo in April 2026, we chose usage-based pricing. This is especially relevant when thinking about usage based pricing SaaS.

Furthermore, not seat-based. Not a flat monthly fee. Usage-based: you pay for the sessions you run.

Additionally, here is why we made that choice, what it required to build, and what I would tell a founder considering the same decision.

Why We Chose It: Understanding usage based pricing SaaS

In fact, the alternative was seat-based pricing. $X per user per month, scaled by team size.

Additionally, importantly, seat-based pricing has one big advantage: it is predictable. Customer knows exactly what they will pay. You know exactly what you will earn.

But seat-based pricing has a problem that became obvious once AI agents entered the picture.

In fact, notably, seat-based pricing charges for access, not for value. You pay whether you use the product or not. For a small team that uses the product heavily, it feels like good value. For a team that uses it occasionally, it feels like waste.

Indeed, more importantly: seat-based pricing punishes efficiency. If a team of 10 could get the same outcome with 5 people using the product more effectively, they would pay 50% less. The pricing model creates an incentive against adoption.

Indeed, usage-based pricing inverts this. You pay when you use the product. Heavy users pay more. Light users pay less. There is no penalty for onboarding fewer people.

The philosophical argument is simple: usage-based pricing aligns our interests with the customer’s. We earn more when they get more value.

What It Required to Build

Usage-based pricing sounds simple. It is not.

Here is what we had to build:

Session counter. Every session needs to be counted and attributed to the correct account. The counter has to be accurate, because incorrect counts directly affect billing.

Trial limits. During a free trial, sessions should be capped. Building a trial cap that works correctly under concurrent usage required careful thought. We had to handle: two sessions starting at the same time, sessions that started before the limit was reached, and usage alerts at 80% and 100% of the trial cap.

Overage billing. When a paid account exceeds their plan’s session limit, we bill for overages through Stripe Metered Billing. This required Stripe meters, usage records, and a reconciliation job that runs nightly to sync session counts with Stripe.

Usage indicators. The product needs to show users how much of their plan they have used. This requires efficient queries that don’t create N+1 problems on every page load.

Lifecycle emails. Usage-based pricing needs email sequences that trigger on usage milestones, not just on calendar dates. We send emails at 80% and 100% of trial usage, and at 80% and 100% of paid plan usage.

Furthermore, all of this required roughly six weeks of engineering work across multiple PRs.

The Complexity Problem

Additionally, the complexity of usage-based pricing compounds.

When something goes wrong, it is not obvious whether it is a product bug, a billing bug, or a usage counting bug. We had a bug in April where a Stripe webhook race condition could result in the wrong billing state. The root cause was in the ordering of two webhook events, not in the usage counting itself.

In fact, usage-based pricing creates tight coupling between your product usage data and your billing infrastructure. Errors in either propagate to the other.

Also, notably, importantly, per-seat pricing, by contrast, is mostly decoupled from product usage. The billing happens monthly regardless of what the product does.

Furthermore, importantly, notably, for a small team, the complexity of usage-based pricing is real. It requires more infrastructure, more edge case handling, and more careful testing than per-seat.

What I Would Tell A Founder

Indeed, if you are early (under $100K ARR), I would think carefully before choosing usage-based pricing.

The philosophical alignment is real. But the engineering complexity is also real. And early-stage founders usually have limited engineering bandwidth.

Furthermore, for us, usage-based pricing was the right choice because:
1. It matches how our customers think about the product (they care about sessions, not seats)
2. The alternative (per-seat) would have been odd for a product that can be used by a customer with no seat at all
3. We had the engineering capacity to build it properly

Additionally, if those conditions do not apply to your product, per-seat may be simpler and good enough to start.

In fact, usage-based pricing is not inherently better than per-seat. It is better when it matches how your customers experience value. It is worse when it adds complexity without a corresponding benefit to the customer experience.

What We Learned

Three months in: the billing infrastructure is solid, but the usage counts are still the thing I check most carefully. Any anomaly in session counts is a potential billing issue.

Moreover, the feature I am most glad we built: the session counter with atomic incrementing. Getting that right early meant we have not had a billing discrepancy since launch.

In addition, the feature I underestimated: the usage indicator in the product UI. It sounds simple. It runs on every page load. Making it efficient without N+1 queries took longer than expected and required explicit eager loading in every query that displays sessions.

However, the thing I would do differently: start with the simplest possible usage model and add complexity later. We built the full overage billing system before we had paying customers. In retrospect, a flat tier with hard limits would have been sufficient to launch and learn, with overage billing added once we had real usage data to calibrate against.

George Cheng is the founder of Viewabo, which launched usage-based pricing in April 2026.

For additional context, see recent analysis from OpenView research on trends in this space.