Episode Transcript
So this week, I wanted to talk about something I'm I'm seeing related to usage based pricing versus recurring revenue. So this kind of came up for us internally because levels Pieter levels. Came out and was talking about generative AI apps and how insanely high that churn levels are. And I think part of the reason is that a lot of these tools lend themselves to usage based prices versus recurring revenue. And so.
As the economic environment is changing a little bit. I'm seeing increased demand for usage based pricing over what was unquestionably, recurring revenue products. And by that, I just mean nobody questioned whether you should, if you're starting a software company, have a recurring revenue, right. Some kind of Stripe subscription, nobody even thought to do it any differently.
There were some products that might have occasional adjunct.
Usage based tiers, but mostly it's all monthly subscriptions. So for instance, we have a product screenshot API, and the way that we do it is we have a monthly subscription that includes up to X screenshots. And then if you go over that based on your tier, then there's overages. One of the problems that we would have. If we move screenshot API over to a a hundred percent usage based pricing as is. And this happens a lot, even with monthly subscriptions. The credit card fails. They've already used the product and they're never ever, ever coming back. So basically somebody could come in, hammer the heck out of the API, get whatever they need done and have the credit card just be canceled. And, and you're never going to hear from them again.
This happens much more frequently than I would like to then I would like it to. Even with our normal, just monthly subscription pricing. But that could be even more accented with a usage based pricing where on a, on a batch basis, right. Maybe once a month or once a quarter, they need to compile some huge list and call your API many thousands of times that might result in a several hundred dollars one time charge. However, if that card fails, then maybe they just sign up with a different account next time.
And they just keep, they just keep doing that. There's of course, a bunch of ways to mitigate something like that. But man, even with the current state of Stripe and how nice it is to get subscriptions going quickly. It is still a lot of work just to make those subscriptions work. Right. There's all kinds of different nuances and different like little if statements that you have to write code for, for different businesses, if this fails and people want invoices for everything and, and all kinds of stuff like that.
So. Even with Stripe monthly, just regular, straight, monthly subscriptions are still kind of a pain in the ass, even with the Stripe checkout links. And even with their like new billing portal where individual customers can manage their own subscriptions and upgrades and stuff, it's still kind of a pain in the ass.
You still have to implement the web hooks to upgrade people correctly. All that kind of stuff is still, it's still work. And usage based pricing introduces a bunch, a bunch more issues that Stripe just doesn't do very well. So I think that opens up some opportunities for tooling and I've seen a couple different vendors trying to come at this problem.
The, the annoyance though, is that. Man Stripe is a little bit expensive. So if you start selling high ticket prices, you'll see this in particular, right? You get a $1,500 a month customer, and those stripes, you start to add up. It's like a few hundred dollars each time. And it just feels really, really silly that I need to pay $300 a month just to have somebody be charged $1,500 a month.
So. I've been looking for a long time for better ways to figure this out. And you know, maybe fed now plays into this a little bit. Maybe there's just straight ACH stuff. In the future where you could actually just bypass Stripe, stupid fees and all the kind of credit card rails and stuff like that. But we're not there yet today.
One of the cool tools I found recently it was called Lago. And it's open source and I just downloaded it and installed it. And it's got a bunch of integrations into different payment providers. So what I think it does is you can create all these billable metrics, so API calls for your API product or whatever. However you want to bill and create all your plans and stuff like that.
And coupons and customers, it will just create the invoice. And then what I believe it can do is through this Stripe integration automatically do the trick to do the charging for those invoices, which would be really. Nice, but you're basically just using Stripe as an invoice. Some way to actually collect the payment.
But something like this would be really helpful, but still, this is just a series of APIs that I have to go integrate. And it's a, it's a big pain in the ass that it's not It's still not clear to me in terms of how you might mitigate some of the issues of, of people using the product and then not paying particularly with Indian customers and whatever the heck they have going on over there with the war on recurring payments. But there are just a ton of failed payments from.
That region, and I think it's a no fault of the consumer. It's just that the country seems to be waging more on, on recurring payment plants.
So I'm pretty sure even with a tool like Lago, I would still need to be building all of the logic, the business logic for when to charge an invoice. So do I do it every day? Right. And then a customer sees like, you know, one charge per day. Every time they use the product, I feel like that that might cause, or have some implications around churn. There's also a bunch of different implications around metrics. Like how we take for granted these metrics like MRR or LTV, or like cohorts or retention, all of these things take on a slightly different meaning when we're talking usage base, because. If I'm somebody that needs to, let's say, and this might be a bad example, but let's say I have a compliance type product.
That once a year, I have to go into the tool and update my documentation to get another certificate. Like, I dunno, let's say it's loosely some SOC two compliance thing that every year I need to go and do one thing. Is that customer inactive because they only use it maybe 12 days of the year. No. There that's an act that would be considered an active customer. So that's kind of an extreme example on the lower end, like maybe for a screenshot IPI in particular, some people have batch things that they need to do once a month or once a quarter. If they use the product one day every month.
Yes, of course there are monthly active user, but that's that doesn't quite tell the same story as if they're logging in intermittently for like a social network versus some usage based product where they log in. They do the thing they need to do, and then they leave. You could think of mid journey in this way, too, right? Like there, I think they charged her the last time I checked, they have some weird pricing where it's like, I get X amount of minutes on a server and like,
I'm a developer. So I kind of get what they're doing, but to the layman, that doesn't mean anything. Right. That's a super confusing thing. It's like, let me just come in and you know, once a week or once a month, or whenever we're doing anything, I just go into the tool and. I use it. And you just charged me for what I used. So TBD on whether this economic environment will change the way that SAS is being charged, because it's, it's kind of a fun exercise to think of.
Any type of SAS product and see how it could be turned into a usage based pricing. And I think the exercise is cool because it, it pinpoints where the real value is being delivered for the product. So super send is an email sending tool like, like Lem list or Apollo or HubSpot without the CRM. So you might, you might transition that to a subscription-based application and that metric might, if you were just to pick one, might be the number of messages sent per month. So.
Every time super sends, sends a message for you. That might be, I don't know. To a penny or so, you know, whatever the pricing is, screenshot API. So this is literally an API. We could just charge based on the number of screenshots per month. Cold DM sends Twitter DMS, which is a whole can of worms given all this stuff. Mr. Musk is doing with Twitter, but you could charge based on the number of DMS per month sheet best basically turns a Google sheet into an API.
Many people use this for like gaming or, or a little gaming, like leaderboards internal tools, et cetera. We could just turn this into a number of API calls per month. That would be pretty straightforward. Growth bar, our newest acquisition. It's sort of charged in this way already, but again, it's a monthly subscription.
Based roughly on the number of articles per month and, and a few other things, but we could in theory have a charge just for the number of articles per month. What starts to get more interesting is when you think about what kind of products require some kind of monthly subscription, as opposed to some kind of usage based subscription.
And what's cool about growth bar is it's not just an AI writer. There's. There's a whole, let's say 50% of the app, which is also the SEO research, which is sort of an ongoing thing that you might want to keep track of certain keywords. That you are currently ranking for and track that over time and you might want to log in and change those, like once a week, every couple of days, or once a month. And that part justifies a monthly.
Subscription. Whereas if you're generating a certain number of articles per month, that might be, that might be more aligned with a subscribe the usage based pricing. But that's, that combination makes it a little trickier to figure out Cold email studio. The agency might, if it were to transition to sort of usage based pricing. And the agency world is called performance-based pricing. We could charge based on the number of meetings that we book per customer. So, this is just a little food for thought based on some of the things that I've been seeing and habits too. So I am a relentless tire kicker and sign up for any and all AI tools that are new and look interesting. And I noticed that as whenever somebody tries to gate access by putting the credit card in and say, you're signed up for a free seven day trial or whatever, I'll happily put the credit card in, but I just go in and cancel immediately because.
I'm going to forget. I don't want to forget that it's you know, Gonna bill me in seven days and I don't want to like put it on a calendar and like log back into the thing. I just want to like go and kick the tires around and prove to myself that this thing isn't as good as the landing page.
Made it sound like sometimes that's not true, like mid journey. It's actually really, really great. But I just noticed this habit and a few other friends that are doing the same thing to you, just, you know, log in and cancel it right away, just because you just don't want to be charged. And it's really more of a usage base thing. And not really justified for having like a full monthly subscription every month.
That being said, I don't know what the revenue implications for something like this would be, I think the revenue implications might actually just be lower which I don't know that we would want to. And at least right now, switch, screenshot, API, and sheet best. To usage based, even though those two fit perfectly well into usage based pricing, because they're both just straight API products.
There are little gems in our portfolio. They just keep growing. And but I think that if we were to change it to usage based pricing, The total monthly revenue for those products would go down. So there's a little bit of tension there between what consumers want and what the business needs, because frankly, if we just switched to usage based pricing, I don't know that. I don't know that we could profitably run those companies anymore. So if you guys have any thoughts on usage based pricing, or if you have any tools that you found that solved this issue for you. Send them over. I'd love to check them out.
