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.
Feb 2022 Update
Metronome has now emerged from stealth with a healthy Series A:
18:58 PM - 01 Feb 2022getmetronome @getmetronomeWe’re excited to announce our $30M Series A led by @a16z! Read our co-founders’ blog post introducing Metronome to learn more. https://t.co/k745qe4WA9
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.
Top comments (2)
Enjoyed reading it. Thanks for sharing your insights.
If I read you correct, looks like for Netlify it was the right move to shift from subscription to Usage-Based, and they have not looked back.
The cons you cite I believe are all a function of an emerging domain/category...and will be addressed with time and purpose built solutions.
We are finding that companies are realizing that shifting to Usage-Based is not a step function (a feature change) but a full out overhaul. As you have chronicled about Netlify.
Ultimately, business alignment drives everything. Increasingly, customers are becoming more wary of shelfware (subscription amount paid but value not realized) and are warming up to the new model of - pay only for what you use, as the more fair and transparent business model.
You are right - surprises etc. have to be dealt with. But I consider that more of a company's culture and optics (how they wish to treat customers) than a limitation of the business model.
If this solution was available to you at Netlify, would you have considered it?
youtu.be/45qHczzQOX0
Puneet
Love the article. You're 100% right, usage is a feature, which is why any company that's building a usage only business will get left behind and can never build a billion dollar business.
The issue is that many systems you listed above solve for consumer or SMB usage needs. They fail to understand enterprise use cases where usage is just a feature, but the volume and complexity is much higher than their models and infrastructure can handle.
At MonetizeNow usage is just a feature, just as subscriptions, invoicing, etc is. We are the only platform solving monetization for B2B SaaS.
We should talk :)
linkedin.com/in/jeffgibsonsf/