swyxA 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.
Feb 2022 Update
Metronome has now emerged from stealth with a healthy Series A:
Sept 2021 Update
I had a great chat with Puneet and Lior from Amberflo who are actual experts in this area:
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:
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.
- There are a litany of blogposts and lists and VC quotes on the benefits of usage based billing that I won't repeat here: aligning your pricing to the value you deliver, automatic "upsells" (accounts increase their value to you with no renegotiation), better attribution. The serverless movement is surprisingly aligned with the move to usage based pricing - instead of renting out a $5 a month box, you are now paying per function invocation.
- There are downsides that aren't talked about as much — users now run build-vs-buy decisions every time they code, users fear "denial of wallet" attacks (since most platforms conveniently forget any spend limit features), and I now have to spend an hour in Excel just to figure out what moving any given site to Netlify will cost.
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:
- Twisp (not public)
- Octane
- Plangraph (not public)
- MonetizeNow (semi-private)
- Metronome (not public)
- Chargify
- ChargeBee
- Amberflo
- RevOps (historically for sales agreements, but just expanded to usage)
- Tackle
- Unnamed Stripe alum
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.
- 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.
- In order to give product/sales maximum control over pricing, you should be able to decouple pricing decisions from code as much as possible, allowing things like A/B testing of pricing and retroactive/hypothetical simulations of pricing results, all done without developer help as much as possible
- Open question: if we were to implement hard limits or a credit system, should the billing system tie in to authorization? Would it slow authz down unacceptably or post unacceptable risks to uptime?
- Open question: should the billing system tie in to the observability/metrics stack? it seems like there is a huge amount of overlap, but also having all your eggs in one source of truth seems like a very big risk to take if something happens to it.
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.
