swyxio / swyxdotio

This is the repo for swyx's blog - Blog content is created in github issues, then posted on swyx.io as blog pages! Comment/watch to follow along my blog within GitHub
https://swyx.io
MIT License
336 stars 45 forks source link

Why Isn't Usage Based Billing A Bigger Category? #175

Closed swyxio closed 2 years ago

swyxio commented 2 years ago

source: devto devToUrl: "https://dev.to/swyx/why-isn-t-usage-based-billing-a-bigger-category-m8b" devToReactions: 7 devToReadingTime: 5 devToPublishedAt: "2021-08-23T08:28:32.312Z" devToViewsCount: 562 title: Why Isn't Usage Based Billing A Bigger Category? published: true description: Usage billing is the new hotness for SaaS, and I have personally seen the pain it caused, but I was ultimately scared off from investing in it. tags: Reflections, Pricing slug: why-usage-billing cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kcy7senuwbb42gd7yjhw.png canonical_url: https://www.swyx.io/why-usage-billing

A recent episode of SEDaily discussed Usage Based Billing but remained fairly superficial. I went down this rabbit hole a few months ago and came out uninspired — here are my thoughts on it.

Oct 2022 Update

Anhtho from Lago sent along her thoughts on why Stripe Billing isn't enough for usage-based billing: https://www.getlago.com/blog/is-stripe-using-stripe and also shared this piece on separating entitlements from billing plans.

Feb 2022 Update

Metronome has now emerged from stealth with a healthy Series A:

{% tweet 1488587468135813120 %}

https://www.getlago.com/ is another new player.

Sept 2021 Update

I had a great chat with Puneet and Lior from Amberflo who are actual experts in this area:

{% youtube zelDLiG4SLE %}

Akash from Octane was also on PodRocket.

My Story

I remember the time when Netlify went from subscription-based billing to usage-based. We used to have 4 tiers: Free (1 user), $45/mo (5 users + Password protection), $290/mo (10 users + RBAC), "Call us" (SLAs, special CDN, etc). We moved to the seat+usage based model you see today: $0/19/99 per user plans + clear limits for 8 features from Functions to Build Minutes.

It was possibly the most painful, yet high-revenue-impact work that an engineer could do. Over the course of >12 months we painstakingly instrumented every single part of the platform to not just work, but charge real money for the work we were doing. First we started metering bandwidth, the most obvious usage to charge for a web hosting company. Then, new charges for build minutes, quietly rolled out via email. Then over a year later, the journey ended with usage charges for everything else. (This happens to exactly match the main components of cloud businesses: Networking, Compute, and Storage)

To be clear, as a DX Engineer I wasn't personally involved, so you are reading an observer's account of the problem, but I remember thinking at the time that this was a huge pain point. It took one of our most senior/capable engineers leading this project and we desperately wanted a "Billing Engineer" to lead this but it didn't seem a particularly attractive job to engineers. It wasn't particularly rocket sciency code, there were a lot of fiddly details to get right, and if we screwed up something we'd have particularly embarrassing consequences:

{% tweet 1418567795021950982 %}

But it was also clear to me that this was important work — you can't get any "closer to the money" (a concept I discuss in my Career Strategy chapter) than literally working with money on billing. Everyone says the single biggest lever on your business is pricing. If your billing code directly helped change the pricing model which resulted in 2x'ing revenue overnight and 100x it long term, isn't that a big deal??

Pros and Cons

The move to usage based billing proved a good move for Netlify and was surely a factor in raising our Series C.

The Usage Based Billing Landscape

So when I heard David Ulevitch mention that all SaaS companies were facing the same usage based pricing problems we had faced, I got very excited. Whenever you have a boring-but-important feature you potentially have a great horizontal business on your hands. I asked for a list of who was working in this space and got a dozen DMs from people working in this space:

There's loads more getting into the game — Just a simple search of "Usage Based Billing" yields more names like Recurly, Cheddar, Paddle, SubscriptionFlow, and Zoho.

It's more than just Billing

Stripe itself of course does Metered Billing, and I got a confused DM from a couple of Stripe folks asking why that wasn't enough.

Why I was scared off

I was debating incubating, angel investing, or even personally working on this space myself, just based on how painful and how beneficial this journey was at Netlify. Ultimately I was scared off by the competition, and my inability to articulate some deep insight that Stripe or someone else might not eventually just build. I also was tempered in my TAM expectations when I saw that Zuora is still only at a $2b valuation.

Ultimately I think Usage Based Billing is a feature, not a product.

arnons1 commented 1 year ago

I don't have enough experience to REALLY know here but I would guess that most complex enough usecases require a whole data pipeline before actually making the Stripe call - aggregating the usage data, throttling extremely high frequency data, making it auditable, and applying discounts and discontinuities to the pricing or consumption function.

Absolutely. On top of everything you said - you have to consider retrying because a Stripe call can fail. You also have to consider edge cases - for example, what happens if a customer moves from one plan to another? Ddo you copy usage, do you bill for it immediately, do you "repeat" it on the new plan, etc.

These are things that these platforms and tools can guide you on but probably can't decide for you, so the implementation is left up to individual companies and use-cases