3 posts tagged with "pricing"

Everyone in usage-based pricing says enforcement has to happen at runtime. We agree. But that word is doing two different jobs, and the difference matters more than it looks like it should.

At runtime is about timing. The check happens while your code runs, instead of in a nightly job or at month-end.

A runtime is a thing. An execution environment that loads code and runs it.

We mean the second one. Your pricing policy is a document with logic in it, and that logic runs inside your process. Not a fast API call. Not a cached copy of your limits. The policy itself, running where your code runs.

If you're building an AI product in 2026, you're likely managing a cost structure that your pricing model was never designed for.

Traditional SaaS pricing — flat tiers, per-seat subscriptions — was built for near-zero marginal cost software. It made sense when the cost to serve a new user was effectively nothing. AI and agentic products don't work that way. Every model inference costs money. Every API call has a price. Your most active customers might cost you 10x what your least active ones do.

We hear a version of the same story over and over in customer calls.

A founder has a usage-based product in the market. They have some customers. Their pricing "works" — in the sense that money is coming in and the product is shipped. But when you ask how they're tracking usage, enforcing limits, or calculating margins? The answer is almost always some version of: "We build an in-house solution that works for now".

That's not a failure. That's just how early-stage companies survive. You hack things together. You make it work. But at some point, usually right before a major product launch or a new set of features hits the roadmap, that manual scaffolding starts to crack.

This post is about how to think through pricing before it becomes a crisis. What the data says. What we're seeing from companies in the field. And what it actually takes to build a model that can grow with you.