How to Build Billing That Can Keep Up With AI: Lessons from Vercel, Stripe, and Schematic

So when I was running pricing at a company called Automox, uh, started running pricing when the business was doing about $10 million in ARR, left the business and left my role in pricing at about $40 million in ARR. Through that journey, every time we wanted to make a change to pricing, it was a 2-quarter engineering sprint, um, and that was unbelievable to me. It really is what led me to co-founding Schematic with Ben and Gio. And so much of that problem comes back to how we architect pricing. And somebody said this to me a year ago. They said, price is a number, pricing is an architecture. And I love that idea. And that's really what Ben and Shar are going to be talking tonight about. It's how do you think through and build billing architecture in such a way that you have the flexibility and the agility and the iteration pace to be fast and competitive in a market that we obviously all know is extremely fast-moving. So by way of introduction, Shar is a great founder. His, his company was acquired by Stripe. He led a lot of the progressive thinking around Stripe's billing product for the last few years. He recently left Stripe and is now leading billing at Vercel and leading a lot of the thinking at Vercel. So just, you know, some exceptional thinking across some companies with massive scale. Ben is the founder and CTO of Schematic and is, you know, actively every day trying to build a lot of this architecture. So I hope you get a lot out of this. And without further ado, I'll leave it to you guys.

Yes, thank you, Fynn. Thanks everybody for joining today. Wanted to do a quick straw poll maybe before we start. Has anybody here watched or listened to Fynn Glover's podcast, The Monetizing AI? How many people have seen it? Okay, some super fans here. So one of our formats there is the kind of like a roast that we do. We'll pick on a company and roast their pricing page, roast their billing. And the Vercel episode for that was ended up being kind of like one of our touchstones that we refer back to and kind of point to Vercel. It's like, okay, this is how you should do it. This is how you should do your billing experience. This is how you should do your pricing page. So we're really excited to have Char here as, you know, the one who kind of owns that at Vercel. And originally Char and I were going to do separate talks, and then we started comparing notes and it was kind of the same talk. So we decided we would kind of merge minds here and kind of do more of like a fireside chat and talk through some of these issues that we're both thinking about every day. So thank you, Shar, for joining. If you want to say hi.

Yeah, thanks for having me. Yeah. Hi everyone.

Shar's dialing in from Northern Virginia. So I guess both of us, like I said, we kind of came up with a lot of similar ideas that we decided to just discuss together. And a lot of it was to do with this idea of pricing agility. So I guess just to start off with kind of the Q&A here, the first question one might ask is, why should I care? Why do I care about pricing agility? So what do you think about that, Sharm?

The crux of it is the billing architecture needs to support the fast pricing iteration. And there has been a lot of research on pricing being the most impactful lever for growth. I believe Kyle also had a deep dive on this a few years back. There's a lot of different research. Um, but billing was hard and is hard still. And historically, I think traditional SaaS businesses were able to get away with updating pricing every year or so. Um, but that just can't cut it anymore. I think pricing changes cannot be on the back burner with AI in the mix. And I think there's a lot of reasons for that. But there are two core reasons, I believe, and one of them is, uh, AI is fundamentally token-based. So you end up either pricing based on tokens or some combination of credits or usage-based in Arria's. It's gonna be usage-based. And that means you're going to, one, these models are, are gonna change in pricing fast. Their new models are, are getting out frequently. So you, you're gonna have to adapt to that and you have to support that pricing model. So that means you can't, change pricing every 6 months or roll out a new pricing every 6 months. And the second reason for that, I think, is just the velocity of shipping has changed. You're shipping much faster, which means you're going to want to monetize those features faster than you used to. So pricing is really not something you can put on the back burner. And to put that in perspective, actually, at Vercel, We launch a lot of pricing changes. I think we have average of 5 to 6 pricing changes per month, and those include things like new SKUs, add-ons, or packaging changes, basically.

Yeah, I think that's exactly right. And yeah, it really is true. We hear a lot about, you know, we're in this new era, a new AI era. And with monetization, it just, it seems to be very true. There's many levers that have shifted, whether that's you know, the change of the amount of variable costs or just the move to more complicated billing formats. So I thought Kyle's slide earlier about, you know, how many people are on seat-based billing last year versus this year versus they expect next year and just that falling off of a cliff is exactly what you would expect with AI and it's playing out exactly like that. But unfortunately for people who don't like complexity, you know, those billing models are being replaced by usage-based, outcome-based, credit-based, things like this that are much more involved to implement in a, in a codebase and a product. If we do believe pricing agility is important, uh, we should talk a little bit about what gets in the way. So what slows down? So I'm curious, kind of in the Vercel context, like what have you run into or in past companies?

I guess my experience is both Vercel and companies I worked with when I was working on Stripe billing and my startup. Um, so there are 4 common reasons I have seen. Along the way, and there are obviously a lot of things that could slow you down, but I think these 4 are the top ones that I have seen just being very gnarly. The first one is just multiple places to change your pricing. Now, the most common one in this one is you typically start with a self-serve PLG motion, and then at some point you add sales motion because you got that one enterprise customer who's coming in and wanting a custom rate, and now you're adapting, adopting like a CPQ tool or quote coding tool or what have you. And now this coding tool ends up having its own pricing mod— source of truth. So then you kind of split between your PLG have one source, your SLG has one source. And then this kind of, as you scale, the number of places where you are kind of putting what prices exist increases. Another example I've seen is spend management, like the alerting tool ends up having its own, like, source of pricing. And the way this actually slows down price changes is one, you have multiple places to go out and, and make sure it, it, they're in sync. So you end up with a lot of incident potentially if, if they're not. And at minimum, the amount of work that you have to do to actually update these places all at once. And the second is you might be changing price types. For example, you go from a basic per unit usage pricing to a matrix pricing, dimension pricing, and one of these few sources support it, but the other one doesn't. And you're, you're kind of blocked at that point because now you have to change your infrastructure to support it. But Ben, I'm curious if you've seen it, because I know you guys deal with pricing plans a lot.

Yes, absolutely. And I think the multiple places to update is a big one. So it might not just be multiple tools. It could be, you know, your CS team needs to know, you know, how to upsell or move people onto maybe your non-PLG plans or your add-ons and having a process for that can get really complex. And if you don't manage it well, it can just become the Wild West with regards to that team, what your training is, what your deal desk is, etc. Even marketing, you know, like the development process around updating assets or even keeping track of where all, you know, your pricing and packaging is being communicated can work on a completely unrelated cadence to even, you know, if you're nailing the product side. So there's just a lot of things to orchestrate and the more you can kind of integrate those pieces all together, the more you avoid these problems in my experience.

Yeah, that makes sense. And the second component, the second one that I've seen slows down, and this one I think is more on scale as you scale. So at a Vercel size, I think the usage understanding and cost understanding. So when you have a large number of SKUs, and a lot of usage-based SKUs, what you want is for your customers to be able to understand what they've been charged for and be able to dig deep into their cost observability, basically. And on the, that's on the self-serve side is usually some sort of a Cost Explorer that you self-serve. On the enterprise side is usually some sort of a public endpoint that you can call and pipe into your cost observability or some CSV export that the finance team is looking at. In both of those cases, the main scalability issue I've seen is just being able to get real-time data, being able to have a single endpoint that actually spits out cost and usage so you don't have to tie those two together. And the second one is like the user being able to tag their costs. One example I've seen is department, for example, different departments want to tag their usage and look at the cost for each of those departments. Those are obviously things that are not priced in, in, in Vercel case, for example, but the user wants to actually see that. So I think in this case, you, you really want a single source of truth for your cost and usage data in one place.

Yep, absolutely. And the SKU sprawl is a huge issue here with, you know, if you don't have the right tooling, it just causes you so many headaches over time. Like, I'd like to hear Daniel saying that we had helped him to sunset some plans, but in an ideal world, you have appropriate tooling where you don't need to sunset plans unless you have a business purpose to do that, right? And as a developer in the past, I found myself in many situations where, you know, some legacy SKU was holding me back from performing some migration or at least moving as fast as I wanted to do, right? And so getting your architecture right up front can help you to not put yourself in that situation.

Next one, I think you probably know a lot more than me, it's entitlements. They are, they could become painful and I've seen it become painful, one in repackaging. So typically when you like roll out a new plan, for example, what happens often is you have hard-coded the if plan X, then give feature why, and as you add more plans, that just becomes very difficult to scale. And on the sales-led motion, the way entitlements become a pain is when you want to give custom rates to your enterprise customers and you're using something like Salesforce, and Salesforce now is the source of truth for entitlement for enterprise customers, but then your product is a source of truth for self-serve customers. And now you have a problem of like who actually owns the entitlement source of truth, but Ben, I, I know you probably have a lot more context than me here.

Oh yeah. And we're, we're gonna get into entitlements more, but you know, it's one of those things that kind of like the SKU sprawl, it starts out as kind of this like pebble in your shoe and just turns into something that keeps you from, from moving. Right. You know, at the beginning, maybe an entitlement looks like customer A has feature B because they're in plan C. Right. And then the next thing you know, it's, you know, customer A has X allocation in terms of credits to this feature per month. They can buy more at some rate. And if they don't use them, they roll over in some behavior. And at a certain point, there's so many variables here that, you know, you're looking at quite a bit of logic that you have to implement to keep up with making sure all the accounting is right, like Gio was talking about earlier. Making sure things are communicated, like you were just talking about. Users have transparency and just, when someone goes to use the product, they get what they paid for, right? So that's the last thing you want to get wrong.

And fourth one I would say is the UX flow. Um, and the UX flow specifically with the product-led growth motion. Um, so for example, we, we add add-ons, uh, every once in a while. And those add-ons, if there's no standardized way to actually implement them, different product teams or different engineers would end up actually just building the add-on on the self-serve flow in a different way. That's one. The trial flow, the checkout flow, all of those could, if they're not, there's no standardized pattern or there's no SDK that you're using to streamline it across the board, it could become pretty hectic to scale over time.

Yep, and that's an area where I've seen one of these just across the board slowdowns where it's just prioritizing the dev work to make the change. Like, like Gaurav was talking about, like you have to make a case to make the pricing change. And if you don't necessarily have the data, you could be spending 6 years to do a $10 price change, right? And, you know, that UI layer is somewhere where oftentimes like getting the dev work scoped, you know, can just be a real slowdown.

Yeah, I actually saw like the other day an add-on that was completely outside of the add-on box that we typically have. And that was a great example of just not a standardized pattern that could happen even at a large scale.

Yep. Well, let's talk about the architecture. So we want to avoid all these problems. There's so many different kind of holes you can step in here. I'm going to pull up some of your slides here, but let's see. All right, yeah, so let's talk about the architecture. How do we avoid this? What should our architecture be to not have these problems?

Yeah, I can actually see the slide, but I think I can just speak through it.

We're on your architecture self-serve sales-led forking slide.

So basically, I think the solution to the multiple pricing problem is being intentional with a source of truth for your pricing. And where I have seen this work well is just have your PLG pricing as the source of truth when you are adapting, adopting an SLG motion or any other tooling. So just keeping a single source of truth is always the way to go. Just down the road, you don't have to worry about those multiple places. And the problem with the pricing type is also going to go away because you're not— whatever your source of truth supports is going to kind of be applied across the board. So both enterprise and self-serve could get the same pricing, or your spend management alerts could get the same pricing, and so on. So just single source of truth is the, is the solution here.

Yeah, I'll go to your cumulative consumption slide.

And that one is actually, that, that's a picture of our usage space, so Vercel's usage page. And behind this, there's a single endpoint that you can call to get both the usage and cost for a customer and for the different dimensions that we have priced. And that endpoint is also available for a user to plug into a cost observability tool or even download the report directly from here. That did not exist before, and, and getting there was kind of an overhaul and just being what existed before was kind of two sources of truth where one was like the cost calculation portion and one was the actual all the prices, all the usage and dimension. So getting that in a single place took a lot of work. So I, if I would do that from the start, I would actually make sure my billing solution can support usage aggregation and cost calculation at the same time with a single endpoint that could spit out usage data for a customer. So I don't have to build that in-house basically.

Yeah. So this is interesting 'cause it ties into this theme we've had today of measuring costs, measuring usage, whether or not you want to be perceived as a quote unquote cost plus, at least correlating those so that you can be fully clear-eyed as you're creating your price model and, and trying to exercise this agility. So we'll go to your next slide. Slide, which is the decoupled entitlements from pricing slide.

I've learned the hard way, but there are, I guess, 4 main things that I would look for in a billing architecture for, from an entitlement perspective. One is that I want the features capabilities that I give my features, my customers be decoupled from pricing. So decoupling those two allows you to change pricing without having to completely change your feature sets. That's one. Second is overriding. So on the enterprise side, usually GTM teams, finance team, they want to be able to get in and, and, and overwrite features. Third one is being able to separate entitlement cycling from billing cycle. So this is also enterprise use case where you want to give the user access to their account, maybe a month before their invoice is due. You typically with billing solutions might not be able to do that because the two, like invoicing and entitlement cycling, is coupled together. So making sure those two are decoupled is a very important piece. And lastly, audit logs. This one comes in at scale, but when it does and you don't have it, it's a difficult problem to solve because finance typically wants to be able to see audit logs of who changed what features at what point and what customers had access to which feature at a given time.

Yeah, but some industries that's even just a hard requirement to have, some customer types. Do you want to go ahead and dive into entitlements more now, or did you have more on this slide?

No, that's it. I actually, I'm curious what you have on entitlements because—

Yeah, I wanted to double-click into that. And actually, before we do so, maybe just another quick poll because So this is, I think, the first talk where anybody's used the word entitlement. So do people have a familiarity with this? Like, when we say entitlements, do people ever use that word? OK. So our definition we use is just the commercial relationship between a feature and a customer or a user, you know, depending on how you, how your application works. But the idea is, like I said, you know, customer has feature because plan. Customer has amount of feature because plan. Customer has more feature because they complained and we gave them a special deal. Whatever it may be. You know, we mentioned earlier all these different variables that can enter in. So, basically, like, you want to allocate this to a dedicated service in your architecture ideally, because of that complexity. So when you think about, like, as you accrue and build up more customers over time, you're gonna have— that just means more and more combinations of all those variables. And so that complexity to me suggests, like, having a dedicated service for this. And so the domain of that service I would typically think of as being two things: customer profile, which is kind of an integrated view of customer subscription and usage data, and then product catalog, which is, you know, what are my plans, which ones are PLG plans, to your point earlier, versus enterprise plans versus legacy plans that aren't on offer anymore. What prices do they have? What features do they have? Is anyone on them? Should I try to get them off of them? All that type of information. So that's the domain. So try to get all that data into your service is my recommendation. And then the really hard thing— my contrast didn't work out here as well as I wanted. The really difficult thing to me about entitlements, the thing you must get correct is the interfaces. So, basically, there's 3 groups of people that matter, right? So, up at the top here, you have your applications. So, that's user land. That's customer land. Then you have your internal users, which is the people operating your business, and then you have your developers. And all those people need to have interfaces into entitlements, basically, for it to work. And those all need to be, to Shar's point, single source of truth. It needs to be one system but many different interfaces. So, your operating user needs to have a good UI for interacting with entitlements, plans, etc. But they want to be in their home business tools, whether that's a CRM or they're getting fed information on a Slack channel, whatever that may be. In your application, you want to be able to report usage. That's typically gonna, you're gonna want that to be an event-based system. In the context of something like schematic, you're gonna want to have like drop-in UI components. 'Cause to my point earlier about SKU sprawl, like Joe Schmo, who's on some plan we don't even offer for 5 years, like chances are the logic of how to show whatever price metric they were sold on 5 years ago is not gonna be fun to maintain in your React components. So just having something you can slap on there and not worry about is great. And then access checks, like to the point earlier on the 4 Ps about protection, I mean, at a certain point, if you're protecting people, you're probably not just cutting off their billing, but you're cutting off their consumption as well. So you need an access check of some type. And the ideal primitive for that is gonna be, like, a feature flag of some type. And then, aside from that, the only other really critical interface is something to perform offline communication with other business systems. So I put a webhook in here. That's, like, the simplest one. But, obviously, there are many ways ways to do this. gRPC, you name it. Depends what, what you want to do. So once you have a system like this in place, what's kind of beautiful about it is you end up with your developer experience being more something like this. So here's just, that was just like some example code of, of taking this approach. So you have some feature that is gated. I should have used an AI example here, but, you know, report generation, it's gated by a simple, very simple development primitive, like a feature flag. You can get a little bit of data like the usage so far during the period, the allocation. You don't need to think about where that data is coming from. You just get a Boolean, you get some numbers, you use them in your UI as you see fit, and then you have event tracking to close the loop, report the usage when it does happen. And, you know, if you've been in a ViBE coding demo for the last 3 years, you've seen people oohing and aahing at React components. That's not the point here. What I want to bring attention to here is what's not showing, which is, well, what isn't showing? Subscription, plan, anything to do with your business, basically. And that is the critical point, because having an architecture like this means that you can accomplish something like this, which means when you want to change your plans, when you want to change your packaging, all of those many, many variables that interact with each other to create, you know, escalating complexity over the years you're running your business are just tucked behind this little, you know, disabled equals not enabled check, right? So this is what, what I mean when I talk about pricing and packaging agility is creating an architecture where You won't know the future. You don't need to plan out all your pricing. You just need to have the proper primitives to tuck things behind so that in the future you can change your mind about things. Oh, I forgot you can't see, actually. Sorry.

Yeah, I see where you are, actually.

OK. So we might be— I think we're running out of time. So let's just assume, like, you've nailed all this. You have all these pieces in place., and you're running with it as a business, it's always important to check your work. So, this is something I was curious to ask you about, Shar, is like, with the infra you guys have, how do you know if it's working? How do you evaluate it? What do you keep an eye on, basically, over time?

Basically, how we measure success of whether or not our billing architecture is scalable and we can change pricing fast. There are 3 core metrics I track and I highly encourage basically every founder to track these. One is how often can you change pricing? This is typically a manual metric, but it's okay, just track it. So, you know, is it, is it 1 day, 1 week, 1 month, 2 months? That should give you like how your pricing agility basically, and it should not take over a week or a few days of being able to change pricing. Second one is how reliable your billing solution is. So I usually look at uptime, typically a 5/9 or more is what you're looking for, and if it's less than that, there is a problem with your billing infra. And the last one is more qualitative, the tickets that you get, the customer support tickets, how many of them are related to billing and pricing or payments or what have you. That should give you enough kind of gauge on whether or not your infra is working.

Awesome. And before we go to questions, actually, did you have anything else you wanted to say about SDKs or the tooling aspect of this? I realized I got too passionate about my entitlements pitch and skipped over it.

Honestly, I mean, I'm in the belief that the future is embedded UIs and, you know, you do not want to deal with billing to scale, you want to build your product. So the more you abstract away all the stuff you need to roll out pricing, the faster you're going to move.

Agree more. Should we go to questions?

Right.

Okay. So what questions do people have? Anything about billing architecture? Yep.

I'm curious more from a kind of like think about systems more upstream from billing, right? And then how they're kind of As you talk about the different sources of truth, the different data infrastructures, so think CRM, CPQs, as you think about those systems, the data infrastructures there, how do they interact with billing? And do you have a strong point of view around what the future should look like? Should there be pretty standardized, generalized kind of like data structures, or do things kind of work as is despite all the various different vendors as everyone tries out different pricing models and go hybrid, all different pieces, components that might have to feed into it.

Yeah, for what it's worth, I don't think this is a solved problem. There's a lot of different sources and you have to figure out how to aggregate them. What I've seen is, you know, everyone piping their data into a data warehouse, but there's also a lot of problem with that. I'm in the belief that your— you need to own the source of truth for all this data. So regardless of how you're storing them, you should kind of centralize that dataset. And also, I think the future is mostly unbundled. So there's point solutions that are doing one thing really well. So this data fragmentation is just going to get— become more and more over time. So I think data warehouse, like piping everything into like Snowflake or something at the scale is what I've seen. I don't know, Ben, on on the different scales if you've seen something differently.

Yeah, I definitely agree that it's not a solved problem and the CPQ side, things like that. You see a lot of new kind of people stepping into the ring to try to make this work better. So definitely not a solved problem. I'll give like my hot take just because I feel like I'm agreeing with a lot of people here today. It's a little off, off topic, but in general, I'm kind of against the modern data stack thing of like pipe everything to a data warehouse. To me, I think you want to have agility in your billing stack, but too much flexibility is kind of a, in a way, like a harmful thing. And what I would much prefer the industry move towards is tools like, really like Vercel and like Schematic in the sense that they're giving you an opinion about how everything should work together and will build in, you know, the CPQ component and make sure the data flows correctly or whatnot. And that comes at the expense of like, I can write whatever SQL query I want. Or maybe that's like the— whoever was talking about enterprise tiers, like that's the super enterprise tier as you give it V-SQL or schematic SQL at some point, whatever, start inventing dialects. But for me, I think like I'd like to see the industry move towards like wider platforms, more opinions from them, like more Linear, less Jira kind of mindset. I mean, I don't think that solves the problem, but I think it would help.

The way you guys are talking about architecture and billing is it seems like they're kind of two different things to an extent, and I think the world always talks about them as, hey, billing is is this large encompassing thing. It covers all of this stuff. How would you recommend people think about it when they're building from the beginning as separate concepts? Because I think if you're talking about unbundling and specific components, you do create this system of record. But I think people have been relying on billing for that. And it seems like the way you guys have talked about it, there are some pretty meaningful limitations just relying on a billing vendor or provider that takes care of things like fraud risk, chargebacks, know your customer, which is totally different from what you guys are talking about today.

Yeah, I think that's absolutely right. My feeling on it is this idea of, like, an entitlement service and especially just leaning into the complexity, leaning into just embracing that that's going to be there. Is newer, so I don't think that kind of line of abstraction that we were talking about was necessarily there when people were starting companies 5 years ago. So to me, like, I would want to tuck a lot of the billing jobs behind that so that then later, you know, if I want to use, like, some usage-based billing platform instead of the usage-based billing feature of the platform I'm on, or vice versa, I can do that more easily. It's not as invasive of a change. And I'm just keeping those jobs kind of in the kind of financial area of my codebase. And I think in this day and age, somebody also was talking earlier about developers having a backup plan and wanting to just be ready to churn from you if you raise your prices. I think that's another thing here. It's like, you hear a lot of people that have various dissatisfactions with various billing vendors, and you want to at least have like a,, you know, viable plan of action there as well, I think. But I'd be curious, Shahar, coming from the other end of the spectrum, what you think.

Yeah, I think this is my— this is a very controversial topic, I think. And it's to my point, like, I think the future is— what was that?

I'm kind of trying to be careful. Yeah. So sorry to cut you off.

I mean, the unbundled world, like, for example, like, I'm looking at Schematic and you guys do amazing job at entitlements. Why would I go pick a solution that does everything but not as well in those pieces and instead pick something like schematics on the entitlement side and maybe different solutions on, on like tax or, uh, invoicing and what have you, like that should be the world where I pick the best tools for their job rather than picking the one thing that does everything but not, uh, not well. I think that's the future. That's where the future is going. And the flip side of that is obviously the data fragmentation part of it that's not been solved because you're inevitably going to have to figure out how to patch and kind of centralize the dataset. So you either pick one solution that does most of the things and use that as a sort of truth and pipe everything to that, or you kind of own the centralized source of truth. And that's kind of my current thinking on that.

Right. Yeah. You're making me realize, like, a very critical point here, which is entitlements can't be done correctly without being invasive to the product, right? Like, like I said earlier, the most important thing is people get what they paid for when they go use your product. And a billing tool is always going to be more focused on the experience of the finance or the accounting, you know, set of user stories. So it's kind of by just nature less invasive to the product, you know. Tool versus entitlements.