How to architect credit-based pricing for AI and SaaS | The Schematic founding team

We're going to talk a lot about credits today. We're going to talk about like what they are, why they matter, and kind of the infrastructure decisions that they have required from us as we've built out Schematics. Hey, welcome back to another episode of Monetizing SaaS and AI. I'm joined by Ben Papillon, Schematics co-founder and CTO, and Gio Hobbins, Schematics co-founder and CPO. But look, if you're building an AI product right now, like there's a very high chance that you've been thinking about whether or not credits make sense for your business. You know, I think people get it like seats and flat fees assume that every customer costs you about the same and gets about the same value out of it. And that was true for a long time. That is not true anymore. As we all know with AI, what it costs you to serve someone and what they get out of it both move around. Basically constantly. So, you know, credits sit in between, right? Like you buy a balance upfront, it's predictable on both sides. You top up when you run low, which if you're the one selling is expansion revenue that feels really natural. If you get to price each action and what it actually costs you and what it's worth to the customer, you're kind of in a better value equation. So credits make a lot of sense for a lot of companies. But the, the reality is going to credit-based monetization is a major infrastructure decision. And the thing that you need to be prepared for is that underneath credits, there are really 3 jobs your billing infrastructure has to do. You have to have a credit ledger. You have to make sure that you have excellent metering and you have to make sure that you have excellent enforcement. You can build all of that yourself. You can buy a couple of those and build the rest, or you can buy the whole thing off the shelf. Um, you know, so it kind of comes down to what you prefer internally, but I'm going to talk with Ben and Gio today about, um, the decisions that we've made from a technical perspective to support companies who are looking to do credit-based pricing, um, hybrid pricing, um, across multiple sales motions and across multi-products. So let's get into it. When people come inbound to Schematic, they're usually saying things like, we want to go to credit-based pricing, or we want to, you know, have, have somebody handle entitlements and metering and credits. You know, when somebody wants to go to credit-based pricing, Gio, this is a question for you, like, what do they actually need?

I think a couple things are going to be true for credits to make a lot of sense. One is you want to move to usage-based and you have a customer base that's accustomed to that and even expecting it, and probably alongside that, you have an AI product that has pretty significant internal costs and you need to control that, especially as we've seen inference costs just go up. And then the sec— and maybe the third thing here is you are hoping to provide a level of predictability to your customers. And both in like the self-service context and in the sales-led context where For self-service, they don't want to be surprised by a bill. They also have familiarity with tools like Claude and ChatGPT and et cetera, where they have a lot of control. They're used to the concept of credits. And then on the sales side, you can sell large amounts of credits on an annual basis. You can set up overage plans and top-ups, and it's a powerful way to sell. You know, with these key concepts present of significant internal costs, predictability, and leverage to expand customers to.

Like, so we have gone out and we've built credit-based infrastructure. We support companies who want to price and package their offering with credits alongside other billing models. I think that there are like several big jobs that your underlying billing infrastructure needs to handle well if you are to do credit-based pricing. Number one is the ledger. Number two is metering, like counting what each customer uses. And number three is enforcement, like checking at runtime whether or not they have credits left before they take the action and then enforcing the commercial policy. Is that too simplified? Would you, would you expand that? Like, how have you built our credit infrastructure and what are the big jobs that you've built it around?

Those seem mostly right. I think the ledger and the metering, there's a lot of overlap there, but it's important to have an immutable ledger so that you can always see everything that happened and there's no kind of changes that aren't auditable. Whereas metering, it's more about, you know, what's the rate of consumption, what was the actual consumption, and how does that relate to the balance? The enforcement is where things really get kind of out of hand sometimes. I think, um, you end up with a lot of situations where if you're fully reliant on your billing system, then you kind of have to build your own enforcement or rely on something that's maybe not going to enforce quickly enough for agentic use cases or use cases that have a lot of associated costs. Um, so We end up building a lot more at that layer, I think. So for example, it's important to be able to do some amount of your credit burn down closer to the edge so that you can kind of fulfill a dual mandate of having authoritative checks, i.e., if you say someone can do something, they can. If you say someone can't do something, they can't. But also avoiding kind of the latency of like a full product integration with billing in order to do that. There's a lot of different kind of hacks you can do to achieve those. A lot of it comes down to kind of like streaming and getting data closer to your clients. There's also kind of like accounting bits that relate to the ledger. So something we built is the ability to pull tranches of credits towards a client so that that's kind of pulled out of the ledger so it can't be spent by other clients, but you can continue to do kind of no-latency consumption against them. Things like that allow you to kind of do credit consumption for HN6 products and not kind of break the bank or deal with a lot of abuse.

A question I get a lot is like, how should I burn down credits? What is— what have you all learned about kind of the best path, the best practice around credit burn down? Like, is it Is it oldest first, newest first, expiring first? Is it first in, first out? Like, are there best practices here that you're seeing?

The most common one is first in, first out. That's what we prioritize in our own product as the main option. There are many other options, but I think for most companies, that's plenty. I think where we also provide more control and where customers or people thinking about credits should be thoughtful is when you have the concept of promotional credits. For, for one, if you want to prioritize those differently, usually people do. That's like the first thing that gets burnt is anything promotional. And then if you have a mix of user-level seats or seat or user-level credits or seat-level credits and company-level credits. Typically those seat-level credits get burnt first and then the company-level second. Then that kind of enables an overflow setup where you're able to allow your, you know, have limits at the seat level, but don't actually block them if they hit their limit and start pulling from company level balance, and that's usually the ordering there.

Yeah, that makes sense. I was going to ask, so like, I also hear a lot of people ask, you know, there's pooled and unpooled credits. And usually there's like a big question of should individual users and their credit use be gated and enforced so that you don't have power users pulling from a company's credit pool. In a way that is unfair to maybe other users. Are we seeing any best practices materialize around this question that companies are asking?

The way I would think about it is un-pooled limits are really a full extension of seats generally, and they carry the benefits and the drawbacks of seats. The benefits are you sell by seats already. Like if you already have a product where you sell by seats and that's how you think about your sales motion, that's how you think about access, that's how you think about value, then it just aligns really well to that. Each seat has its own credit balance. You can, from an organizational standpoint, have a lot of control and visibility over each seat's usage. You have just like hard policies that are easy to enforce and communicate internally. Um, but then the drawbacks are there too. So even before credits, you likely have seats granted to people that barely use your product and seats granted to people who do a lot, and that is like bad value often and leads to people seat optimizing and constantly trying to downgrade their seats and stuff if people aren't using it. Or if you've used a, a tool like HubSpot where if you're inactive enough, it just removes your seat. So those to me are like counter to how things should be. Really, you should allow people to use your product as much as possible, never get in their way, never get in the way of the power users, and don't create an awkward value consideration for your non-power users. So my recommendation, or if there is a best practice, is scale credits with seats, meaning each seat grants you more credits, but keep the limits pooled at the company level so that The power user can use as much as they need. The less power user uses only what they need. And then you're topping up that company balance as the power user, you know, as it runs out. The downside there is you'll have one user who hogs the credits, but I guess I, I don't really see why that's a downside. Like, it seems like that just means you can expand the customer more and you could kind of hit a middle ground there where you can do some seat-level caps to make sure one user isn't like literally abusive with how much they use it. That's what I would recommend.

I'm curious to get your take on like the difference between credits resetting and credits expiring.

Yeah. So with credits, like this kind of calls back to the Ledger story. So credits get into the ledger via some grant of credits, right? And so every grant has to have expiry behavior of some kind. And so that grant will expire at a certain point, or it could be reset manually at a certain point. Let's say like a change of plan or a churn or like an upsell to a different plan where those credits are no longer relevant. You could think of it in terms of a reset, right? Like if you get X amount of credits per period, per month, for example, they're expiring, or you could think of it as usage that's resetting every month and being— new usage is being granted. You also want to consider rollover policies. So some amount of your credits might roll over optionally into the next month. This also ties into the question around expiries. So do you consume the rollover credits first, or after the new credits, usually you would do it first.

Yeah, that's helpful. And maybe, Gio, back to you. So like rollover is really interesting because like the way I've always thought about it is it's like, it's, it's kind of like a, a rule that's designed to prevent like anti-hoarding or something like, or, you know, prevent, you know, kind of abuse of your credit grant. But it seems like it's an interesting kind of commercial tension that companies have to navigate. Um, and I'm curious, like, you know, what you've learned from our customers and how you've thought about this, this as well.

I think rollover's come up a lot less than you would expect in other worlds. Like back in the day when cell phone providers sold minutes, it was extremely common and like a common way to sell. I think the, what it addresses is I paid for X credits. I didn't get to use them all this month. Like, I should still be able to use them. And when I've seen it implemented, it's almost always just last period's credits roll into this period's and then expire in this period's time period. Um, if you let it get more complex than that, it becomes a mess accounting-wise. I think it addresses like, yeah, that just the I do plan on using all that. Don't take them away from me even though I paid. In practice though, I think it's kind of rare. It's a little bit harder to account for. It's a little bit harder to report to the user and, you know, track a more complex balance. So it just depends on the type of product you have, maybe the cost. If you're like a $200 a month plan, you probably don't bother with rollovers. But if you're talking to, in a sales-led world, it's a large contract, maybe there's a little bit, it becomes like a negotiation lever and could be powerful in that way.

You know, one thing that's like, you know, interesting is that historically companies will build a lot of the enforcement side of this. And this is sort of what historically billing systems have advised companies to do is you go build your own enforcement infrastructure and a database with customer state. And then if customer state changes, like somebody like blows through a credit limit or they auto top up or, you know, they roll over, right? These are all state changes., then a webhook will fire from the billing system. You're responsible for catching it. You're responsible for updating your database. Your product then is going to query that database on every customer action to decide what the customer or the user can do. And it feels like maybe this was fine and tenable and acceptable when customer state didn't change that much, but it seems like it's quite difficult and maybe untenable when state is changing all the time. You know, for example, like, you know, Metronome, which is like, you know, a world-class piece of infrastructure for managing your credit ledger, they probably wouldn't go out and say, hey, like, we're going to make a blocking API call to Metronome on every agent action to check if the user can proceed. They're not built for that. Like, they're not this state management system. And so I'm curious if you could talk a little bit about, you know, what it is, what it requires to build the state management system that can do the enforcement on the edge and what you're learning about both building the system and like what you're learning from the market about what they need in the system.

Yeah, it's a really interesting problem space. I usually try to separate out the state management piece into basically two buckets. One is changes a lot, changes a lot in response to user actions. So this would be just continuous usage activity, prompting inference, other usage-based interactions with a product. And then the other is like changes infrequently, more like transactional operations, like auto top-ups of a credit card, grant purchases of your credits, upgrades or downgrades or cancellations of plans, things like that. And for the former, it's kind of like, you don't really want to just do naive caching because then you're just a prisoner of your TTL. Whatever happens during your TTL is not going to be reflected. And then, as you point out, just doing a blocking call for every usage is also not really tenable from a latency perspective. And most vendors aren't going to really support that rate limit-wise either. So what do you do then? I feel like you have to kind of move some of that logic onto the client, right? So you're not making calls to a third-party service, you're making it from something that's more like a middle ground between a cache and a third-party service. And so the way we've built this is kind of like this leasing concept where you pull credits onto a client and then you can interact with them on the client atomically using some storage that you own that's in your VPC. So it's better than caching in the sense of recency and accuracy. It's better than not caching for the sense of latency. Um, and the mental model I have for it is basically like with credits and with usage-based billing in general, you just kind of have like a series of balances stacked on top of each other. Like you have your bank balance and you pull some of your bank balance into a credit balance with that vendor. And then What you can do to solve this problem is then pull some of that credit balance towards your clients for use on the client. And even within the lifespan of a single usage operation, you can do a very small draft against that lease to do, you know, atomic operations to prevent kind of races between concurrent clients. So there's kind of a lot there, but it necessitates finding something that avoids like the traps of the, like the obvious solutions.

Guys, any, any last thoughts on credit-based pricing that you'd like to leave listeners with?

I think this is a point I've made a little bit before, but when thinking about credits and when thinking about your monetization, there's two psychologies to keep in mind. There's the one where your customers are, or your prospects rather, are evaluating your product and your, your product's outputs. And in that mindset, they're very stingy with how they're spending. And you want to be extremely transparent about usage. You want, especially in a free tier, to have hard limits and to be really clear about when you hit a limit. Make it possible to do the minimum thing to keep going, whether that's a small top-up or going to like a slightly more, you know, the first paid plan. And that's where it's okay to introduce friction and transparency because people are still evaluating the value. Um, and they, and they actually value that they're not going to be surprised with the bill and they value the transparency. Then after that, if they gain true trust in what you're doing, and the value of your product, which we've all felt probably with a cloud or what have you, then you want to get out of the way and you want to think about things like auto top-ups where your wallet gets increased immediately once you reach a certain threshold. And people at that point are less cost sensitive. They just never want to be blocked. And so that's also when you start to think about like, okay, company-level overflows or overage models, it just becomes about, we will expand you, but you're going to upfront accept a certain policy. And then you don't have to worry about it unless you go to crazy amounts of usage. And it's just two different psychologies. Credits can be used for both. That's another reason why it's helpful and flexible and popular. But I would urge people to think about how their monetization is viewed in those two lenses.

One thing I would want to note also would just be, I think sometimes it helps to just separate out the fact that the credit is a credit, that it's some other special type of currency, like a token in your arcade of your product. It doesn't necessarily matter. Like, it kind of matters, and there's a vector along which you want to think about how that matters. Like, what is the currency you're you're having your users transact in while they're in your product. But from an application design perspective, you want to think about where are the trust boundaries of your app, right? So credits are a way for you essentially to just have prepaid usage. If you have a lot of PLG, that allows you to then kind of use that as a gauge for trust, right? You can increase the prepaid usage. You can kind of fail open, assuming the auto top-up is gonna work once you have a customer who's got a good track record for paying you, things like that, right? And so, it gives you some things to play with in your application design with regards to the differences between different types of customers, right? Like somebody who has a big upfront contract and they have a bunch of credits that come with that versus somebody who just signed up for a trial and you don't know them versus somebody that's been in it, started out that way and is expanding towards, you know, being a big customer of yours. So it's interesting to think about credits as a way to kind of play with the trust around payments around your product as well.

Guys, thank you so much. We'll do it again soon. Thank you all for tuning in and listening to another episode of Monetizing SaaS and AI.