How Expo Builds Pricing Agility Despite Wildly Different Customer Types

Joe, welcome back to Monetizing, uh, SaaS, which we're going to start calling Monetizing AI. Um, John, welcome here for the first time. Thank you both for being here. Joe, you had this great idea to make this conversation be between you, um, you're leading revenue at Expo, and John, you're leading product at Expo, and I think that's such a brilliant combination. So maybe to kick us off, John, how does monetization work at Expo? Who owns it? How you guys thought about it. It's such a cross-functional practice and function. Walk us through.

So first, thanks so much for having us on the show and talking with us today. Um, when it comes to monetization and Expo, it starts in a lot of different places. Um, we have a pretty wide surface area of things that we work on. We have things that build your Android and iOS and iOS apps in the cloud. Um, we send over-the-air updates to users, and then we also have a bunch of dashboards, which people pay for. And so really where it starts is we try to figure out products that are valuable, and then we try to price based on that, but we quickly run into some problems around that, which is that we can't charge for everything in the same way because value is derived from different parts of the product. And so a lot of it comes from us searching around to like, what is valuable for customers? And then trying to figure out how that gets included in the suite of products that we offer. And then like pricing comes sort of at the end there. So we don't start with it. It comes towards the end. And that definitely has some problems with it, but I think it's worked out for us okay. But it's constantly evolving as the product is evolving. Um, I think Joe can tell you a lot about that, those conversations that have happened. So it starts with the product and then sort of funnels down to after we found something that's valuable, trying to figure out how to get the, um, get the valuable part of the product as the part that we charge people for.

What's super interesting about this, and part of the reason I came on board 4 months ago, uh, at Expo, is we have so many different types of customers. It's not like we can say, hey, this is our segment, this is our ICP, let's just go after that ICP. We have folks, Fynn, like you that might be vibe coding an app on the side, building something that's a passion project, or a developer of 20 years that's working on a passion project and building an app, or an enterprise organization that's trying to build something at scale. And so we have to think about how we monetize each of those personas, and that means pathways and on-ramps into the product and growth pathways that are both predictable Uh, where you can understand the value you derive, like John said, but also some folks may need one or two things, a couple of the products, or they might, might need more of the platform experience where they have to build end-to-end with Expo, which is much more on that enterprise side. So we have all these different types of personas, all these different needs that we have to think about very clearly for monetization.

Yeah, I can see the complexity. It's super interesting. And one of the questions, Joe, I had wanted to ask you is You know, when someone asks you, a prospect, for example, asks you to describe your pricing, and it's like one of the most common questions a revenue leader gets. I was going to ask you how you explain that, but it sounds like at least initially it will completely depend on who you're talking to.

Yeah, absolutely. And as any good revenue leader will say, everything is based on a great discovery. So the more we understand about what a customer is trying to achieve, the better we can present something that's very much what they need and in relation to what they're looking to achieve. So we might be talking to an organization that's coming to us and saying, hey, CodePush, CodePush was deprecated. We're just looking to be able to push over-the-air updates. That's one specific entry point. Oh, cool. How many monthly active users do you have? Uh, this is how many, all right, the price is based on this. Here's where you go as you grow. Or it might be an organization that's saying, hey, we rebuilt our entire app on Expo. Now we're ready to actually launch it and we need all our CI pipelines ready cuz we need to continuously deliver value to our customers as we're building out this app. We actually need everything. We need the suite of products and we need to understand how it's predictable, how it scales, how we actually can use different parts of the product at different times. Because with any app, you might be building features. For a couple sprints, then you might be fixing those features and different parts of our product actually ramp up during the different types of, uh, usage patterns that we have. So that's, that's been really interesting. Understanding that context before you start to talk about pricing is super important.

So John, you mentioned this, you've got sort of, you know, different forms of value in the product. So maybe today, what are the core value metrics against which the business is charging?

Right now we offer kind of 3 big things. Um, the first is that inside the product we organize like everybody's Android and iOS builds, all their submissions and everything that's happened on their team. And we also collect insights on those to tell you like, how is your app doing? For those, I think it makes most sense to charge a subscription-based fee, which is what we've been doing. And so we've got the $20 a month plan up to like the $2,000 plan for enterprise companies. At the same time, people have usage-based things where it's like, I'll run a process that like makes my iOS and Android apps, submits them to the stores, and then slacks my company that there's something new on the store that we need to go and like finalize for review from App Store review. People do those at different cadences based on their iteration cycles with their product teams and their development teams and just how things are going during that time of year. And since that's usage-based, we have usage-based costs on that. Um, so those are the two main ones. Um, at the same time, we also have this product for over-the-air updates, which allows people to send like new JavaScript over the air and fix bugs and make small changes to their app. And that's really based on end users. Um, that's one product that does that. We also have a hosting product for website, uh, for websites and API functions, et cetera. And so we have kind of these three things that we price on. One thing that's been a challenge for us is to figure out how to price on all of these and make it make sense for people. Like, how do you have PLG? How do you have people like self-serve by these things without being like totally surprised by this cost at the end? So that's something that Joe and I have been working through.

Yeah, especially with the different personas again, like a, a business who needs to set a budget, but then also somebody who's Viacode, Viacoding an app and maybe doesn't understand what a CI/CD pipeline really is yet. So we have to educate. As we also establish value both from the sales process, but also in the product, which is super important. And John has done a great job like designing those onboarding flows and getting people to understand what everything is doing. So when they do get a, a bill at the end of the month for an overage, they understand exactly what they got out of that too.

By the way, just as an aside, I think one of the things that you guys do from a pricing page perspective and an FAQ perspective, and even a docs perspective is is you sort of make it clear that one of your principles is predictability. And it sounds like that's something that you had to think about quite deeply.

Yeah, we've heard that over and over from customers, like, please tell us what this will cost. We'd much rather have a predictable cost than have, um, usage based on end users that could be wildly more expensive than we expect.

Just have your reaction on this. I mean, one of the things that to me is so interesting about pricing right now in this, and through the early innings of the AI world that we're living in, is Obviously, you know, an explosion in usage-based pricing, but also an explosion in credit-based pricing. I have kind of long thought about credit-based pricing as sort of a flavor of usage-based pricing, but you could argue that sort of maybe the important difference is, well, usage-based is pay as you go. Credit-based is pay upfront, burn down. Therefore, maybe it is more predictable. However, nobody knows what the value of credits is. So is it really more predictable?

I mean, I think it is more predictable, but at the same time, it's probably less valuable for users, uh, depending on your usage. Like, you just don't use all the credits, then, um, you're paying more per unit, obviously. And then if you use a lot more, then you need to discuss the, uh, spike pricing, or like what happens when you go over, et cetera. What happens when you break that contract? Um, that's, that's something that we're always talking about.

Tell us about that conversation, because right, you could do like auto top-up, you could do overage, like How have you thought through this?

I think there, it kind of gets back to what the customer needs. And we've had a lot of conversations with organizations who really value flexibility and they want usage-based pricing. They want to pay for what they use month to month. And then we have organizations that do an annual budgeting process and they can't go back to that budget mid-year and say, I need more because we didn't plan our adoption correctly. We actually used way more. They also don't want to under, uh, purchase and not use what they're actually purchasing upfront. So there's a predictability versus flexibility trade-off that we're also trying to help the enterprise customers. It's super easy to just say, put your credit card down, pay for what you use. We're balancing some of this out by doing both too. And it kind of depends on the product. So we have a product called Workflows. Workflows are effectively charged by minutes. And we have some organizations that want to pay upfront for those minutes and we'll do a credit drawdown model. But some companies aren't entirely sure how many minutes they're going to consume, especially with new apps. So what we're doing with them is we'll put them on an enterprise contract. We'll put all our products annualized upfront, and then we'll actually have workflows be usage-based. So this allows us to establish a baseline for that product. The customer starts to get the flexibility initially, which they value, but then as they understand the usage patterns in the app, Then we can set something more predictable or annual based. That's very, very consistent and easier to understand when you're planning something with finance. So there's a little bit of both that we're doing. There's a, another conversation, Fynn, that we've talked about and something I thought a lot about at LaunchDarkly, which is usage-based pricing versus usage-based subscriptions. That's kind of what credits lean towards. The most important thing is the meter. It's like, is the exchange of value correct? Then the second thing is the mechanics of it. Are you paying for that in arrears? Are you paying for that upfront? Is it a credit drawdown? And if the pro— if the product is hard to predict and model out, then doing something on a credit basis is much easier mechanically because the customer can go draw down on that and say, hey, we think you're going to get to this point, so let's go with that. It's easiest to do usage-based first, then go credit too. So that allows that customer to say, hey, I feel like I'm getting the value out of this, but I'm also getting predictability on a monthly basis. The final like mechanic here that I actually think is really important to establish with your enterprise customers, that's really strategic partnerships, is there's going to be some months where they consume less than what they commit to. Then there are going to be some months they consume more. And what's super annoying for them is like when you commit to something and you pay, you use less than, it's like, ah man, I pay too much. But then you go over and you're like, oh man, now I'm getting an overage. Well, if you set up the contract to say, we understand that's going to happen over the year. So we're not going to charge you that overage because we know it's going to balance out when you don't use a lot of it. You look for the average on a month to month. That really helps that customer feel like they're getting the most out of the product in a predictable way too. So there's like a third piece of mechanics, which is how do you construct the contract so the customer isn't getting a call constantly from the sales rep when they go over, but they're not going to get a call when they're going under, right? You're not going to get that dollar back necessarily. So I think that's super important when you're establishing the relationship with the customer with a usage-based subscription model.

Yeah, I think that's such a good point. I wanted to ask you. What you're optimizing for with your pricing. And again, I think what I'm hearing is it really depends on the customer, Fynn. Like with some customers, we might be optimizing for flexibility given the way they procure. With some customers, we might be optimizing for adoption. With some customers, it might be something else. Is that a fair playback or, or would you edit that?

Yeah, that seems about right to me. It definitely depends on the customer and what we're trying to optimize for. I'd say like the biggest highest level thing, if someone was like, I won't tell you who I am, tell me about your pricing, uh, is that like, we want to give you everything you need to build apps and get them to the stores and to your users with our plans. And that should probably give you what you need. Um, it's like a Lunchable or something. It gives you most of what you'd want at lunch, but you might want to trade with some friends too, if you have a different situation going on.

Yeah. Yeah.

John went exactly where I was going. You know, our mission is to give you everything you need to build apps. So for somebody who's creating something new for the first time, it's all about speed.

Yeah.

So how do we make it super simple to get into the door, get that product you may need right off the bat? And we have a bunch of open source products too. So that's another on-ramp into the Expo suite of products. For an enterprise company, it is what are those things, the series of things, the bundle of things that they're gonna need to achieve the outcome they're looking for? How do we package that up and deliver to them? In a way that actually makes sense for the Expo business and makes sense for them too. And that's a big thing we're working on. I call that size, like average sales price or ACV for contracts like that in the enterprise.

One thing I'm interested to get your all's take on is how pricing as a, let's call it pricing or monetization or whatever you guys call it internally, but how does it work internally as a function in the business? And maybe you could, just try to create some color around the character of that function, both like how do conversations around strategy, pricing strategy, maybe pricing tactics happen. Similarly, how do conversations and decisions get made around the tooling and the underlying architecture that supports, for example, Joe, subscriptions and metering and quotes? Can you give listeners color on both of those two fronts?

Yeah, so in terms of strategy, the, probably the biggest thing we've done in the last 6 months is shorten down the amount of people who we talk to initially about pricing to like Joe, myself, and our CTO, James. And we go and we figure out like the modeling, we try to figure out what things cost on our end, and then like what would make sense for the product value. And we try to make a proposal that we think will be good and we can generally make decisions. So shortening that down to a small team really solved a lot of the paralysis that we experienced before with including the other 30 people on the team and trying to make sure everyone agrees and then you get hypotheses about how things could go wrong in a million different ways. Um, so that's one thing that I think has been going really smoothly. On the operational side, we're actually still in process on making this faster. And I, I've been reading the Schematic website as well, and I know this is one of the main missions there. And so definitely reading where you guys are going was pretty inspirational to me. Um, but right now we are using Stripe and we've got a bunch of databases that we flow, uh, data into with a lot of different tables. And getting data out of them can be pretty tricky right now. And definitely we're able to make features and we're able to figure out how we want to price on them, but it does take us a little while to actually implement the code that gets someone's like usage into all the right tables, into their invoices and like where we're feeling confident and then tracking it. Um, we are working on a new system, um, now to track all of that, which should be simpler. Um, so we are excited about that, but that's definitely an area where we could improve.

Yeah, cool.

I know you're familiar with that area, probably quite a lot.

Um, while, while we're here, and just because I can't help myself, but Joe, you've, you've thought more deeply around entitlements than almost anybody. How do, how do entitlements work at Expo?

John might be able to answer this question better than I, but I just say, hey John, I think this thing needs to go here, and then he makes the magic happen in the background. So that, as far as I know how it works.

All right, John, how do entitlements work?

This might be a silly question, but can you define entitlements exactly?

For sure. Not a silly question. In fact, I think it's like a word that is only kind of partially understood. But what does someone have? How do you handle what someone has access to based on their commercial context, their contract or their subscription or their limits that they, that are going to evolve with their subscription or contract?

Oh, gotcha. Okay. That makes a lot of sense. So, uh, in our backend, we have on every single user, um, not only their permissions, but like what features they have access to. Um, in addition, um, in our servers, we're tracking like all of your usage and we track usage in a bunch of different ways. Um, most of actually all of the usage that people are using come back to our server in some ways. So we've got like webhooks coming from GitHub to let us know like when you've like kicked off a build, um, for like one of your Android or iOS apps. Whenever we send an over-the-air update, we've got like events firing off of that. And these all go to your account. And we have this system which we've internally dubbed our entities system, which pretty much runs every one of these events through a common middleware. And this middleware says, do I have permission to do this? And then if you do, um, is this something that's billed? And if it's billed, then we send that off to the corresponding tables that we need there. Um, I don't know the technical details, uh, like the code level details myself, but that's generally, um, how that works.

Fynn, an important callout for Expo is we have, we technically have 4 packages, 4 plans, a free plan, a starter plan, a production plan, and an enterprise plan. Within each of those plans, the capabilities are actually very similar. What's different is some things like if you're going to run a build, are you in the priority queue or not? Uh, what kind of support are you going to get? What thresholds of usage allotted to that plan do you actually have? And under the hood, they're really differentiated by the amount of usage you're consuming, not yet the capabilities. So we're, we're actually not even at a place where we're differentiating capabilities that extensively on enterprise versus production, for example, but it is something that we're investing in as we build out a lot of functionality that is specific to an enterprise and the way that they need to understand their usage across their entire testing suite or how their app is performing, uh, or like how their product is performing more from an analytics perspective. And so those capabilities will start to build into the plans as a key strategy for monetization too.

Makes complete sense. And so 2 years ago, I would go around to companies and ask them how they think about handling and enforcing limits. Um, limits being sort of key drivers between plans. And 2 years ago, most people would tell me, We don't really care about enforcing limits. That feels like it's shifted. More people I talk to now, the, the answer is the way we're thinking about limits is sort of twofold. It is one, we want to prevent abuse, especially on limits or calls that might have real costs for us. Two, we view limits as like important inflections to understand from an upgraded and expansion perspective. I'd love for you guys to react to that. How do you all think about limits? How do you operationalize the use of limits?

I think Expo did really well was design a usage-based system upfront. And so if you go use a product and one month you use a lot more, you're just charged for that usage and then you kind of go back into a stable place. So there is technically no limits within the meters that we offer. So you're consuming it, you're using it, and you're paying for it. Then we have that subscription plan on each, on each package, and that'll give you a set of usage effectively. So you're kind of buying into like, hey, I think that amount of usage is what I need. But again, flexibility matters here. If you go over one month versus the other, we just charge you based on what you use. So we don't technically limit anything in any of those meters. It's all usage-based under the hood. And I actually think that's really wise because it gives customers flexibility. It's a little harder on transparency with the usage-based models, but it's like, hey, we, we got to build a little bit more this month than we would historically in the last 6 months. And, uh, it gives the customer the things that they need without having to like go through a sales conversation or go through an upgrade or go to the enterprise plan. It's like, hey, I need extra. I'm going to use it. I'm going to pay for it. We'll be good to move forward.

Yeah, to expand on that, like we really care about the transparency as well though. Like we were just having discussions about like, how can we expose more of like when you're reaching certain parts of your thresholds to make sure that you're not like going way over and you don't even know it. Um, because like some end users started using like a lot of your app in some weird way that you didn't expect. So yeah, we always want to give people some like at least knowledge of what's going on, but not limit you or just like turn something off, especially like if your app starts to blow up on the App Store or something. It'd be a real shame if like the over-the-air updates you were sending just didn't, didn't work. And that was like a key part of like your app working correctly.

This is super instructive on all fronts. We're getting close to time and, and maybe my main takeaway from you all is as you've considered monetization at Expo, it seems like there have been maybe 3 really kind of crucial considerations. One is how you set up the usage-based pricing system. Number 2 is how you balance usage-based with predictability and transparency. And number 3 is how you have chosen to reduce the number of people that are actually making these decisions so that you can move fast. React to that. Is that, do you think that that's accurate? Is that a good playback of the way the business has really kind of approached this function?

Yeah, I mean, I think that's probably more succinctly than I would've put it.

I agree. I think there's a, maybe a fourth that we didn't necessarily talk too much about today, which is testing iteration. And you know, we were talking about in our All Hands Thursday, you know, there's two types of decisions, closed door, open door. Well, all of the pricing decisions we're making are open door. They're not set in stone. We have to learn, especially as we have totally different customers, totally different segments that we're working with. We need to get something out there, understand the impact of it. We made a change pretty quickly because we kind of rallied around a new pricing committee in this decision-making process that John was talking about to change an old on-demand plan that we had that was purely usage-based. You put a credit card in, you don't pay anything upfront, and we shifted it to $19. And we ran analysis and research on all the comps, you know, who was like us, what were they charging? We're like, okay, we think we can do this. And we weren't 100% sure it was gonna be good or great, but we had conviction based on the research and what our customers were looking to achieve. And it has done incredibly well. Over 2,000 people have already signed up for it, and this was about 4 weeks ago, John, I wanna say.

Yeah, it's been nuts.

That change actually gives us more room to go test and iterate. Um, how do we now upsell or introduce a new product to that plan, maybe for another $10 a month? And that's been a really big lift on the business already. So just being able to test and iterate quickly is a huge thing that I think we'll continue to do as the trio within Expo.

Well, maybe that's the follow-up because a lot of companies want to be good at iteration and a lot of companies want to be good at A/B testing and especially around like levers like pricing. And so many of them can't claim to be good at it. So I'd love to really try to dig in on a future call, like how you guys are improving at it and becoming good at it. I know it's a work in progress, but that's not something that's easy for companies.

Yeah. I mean, we're always talking about how pricing is hard. And I think the main thing I've learned is it's hard because it's not a science. I mean, it is in some percentage, but it's a lot of art and intuition that starts things off and having the sense of like what our customers actually value. What could we charge? What's too much? What's not? I mean, you can try to run analysis on these for a long time. But if you want to move fast, you just kind of have to like have taste of what will be acceptable and then try things and then work with people who are also like, yes, yes, and let's just try it and see how it goes. So I think that's been really powerful for us.

John just coined something new. Pricing taste is the thing we will pursue now.

I heard pricing taste and I heard yes, and so there's like something improv about where pricing is headed based on this episode and I love it. So. Yeah, absolutely. Thank you guys so much for doing this. Um, it's been a pleasure. Learned a lot. Hope we do it again. Yeah.

Thanks so much, Fynn.

Absolutely. Super fun. Thanks, Fynn.