There's something deeply appealing about simple pricing. "You need an actuary to decipher your AWS bill, so we're gonna be different!"
Before launching a product you argue about how to make that pricing even simpler. Roll this price into that, don't charge for those, boom we've got 2 SKUs. It's beautiful.
We leaned into this hard when we started Mux. One of our biggest arguments around pricing initially was whether we should have two SKUs (storage and delivery) or three (encoding, storage, and delivery). The thought was that we could simplify to two and just subsidize our ingest costs with storage and delivery. But... we were an early stage startup that was terrified of abuse. We begrudgingly ended up shipping three SKUs. Oh the horror.
Mux Video pricing circa 2018(ish)
Then come the customers. The customers with wildly different usage patterns and expectations. It's weirdly expensive for some, too cheap for others. The large contracts are hard, the smaller contracts are somehow harder. Sales starts needing to create bespoke contracts to cover those use cases. Everyone feels pain.
That's the catch for simple infrastructure pricing: if it feels too cheap to be true, someone or something is subsidizing your use case. For example, flat-rate "unlimited" pricing in infrastructure is, fundamentally, a cross-subsidization model. The math works like this:
This isn't inherently bad or unethical, it's a rational response to the puzzle of trying to create infrastructure pricing that feels approachable. But...it creates a set of problems that compound over time.
Whenever you see something "unlimited" on a pricing page, ask questions, especially if you believe there's material cost there under the hood for the provider. If someone charges you $20/mo for "unlimited bandwidth," it's almost guaranteed that you'll get a call at some point when you've crossed that threshold and it won't be nice.
Note that after a few of these public blowups, Vimeo stopped advertising "unlimited bandwidth" on their pricing page, and explicitly has bandwidth limits. From Vimeo's blog post on their updated pricing:
This means that if a single user requires an exceptionally large amount of bandwidth — likely driven by the number of viewers consuming their content — then their costs can quickly scale above what our flat subscription fees were designed to support.
Cloudflare's ceiling for a conversation around their unlimited bandwidth offering seems to be much higher (hundreds of TBs), but they'll still come knocking. Yes, some of those linked use cases were clearly in violation of their terms and conditions involving image proxies, but the point remains: if you see unlimited, dig deeper (i.e. actually read the terms).
Our core pricing unit for Video is a minute of video content, which scales naturally with costs.
But we had a more subtle problem. Encoding a minute of video is much cheaper for 720p than 4k. Same for delivery and storage. One price per minute of video meant companies doing lower resolution video were over-paying, and companies with higher resolution video were under-paying.
This is the Subsidization Problem, and it only really hits when a customer starts to scale.
A customer who is under-utilizing looks at their bill, compares pricing to other offerings, and realizes they're paying more than they should be. You can try to address this case-by-case: "We'll just give Customer XYZ a lower rate because you know they're not going to use everything." But then Customer XYZ starts sending higher resolution video and suddenly they're locked into a low rate and you're underwater.
As the provider, we'd created a weird incentive where we wanted our customers to use less of our product. At one point we bundled in Static Renditions (MP4s) as an included feature. The customer uploads a video, they don't have to think about whether they want MP4s or not when estimating their pricing. Sounds simple, now they've got one less thing to figure out.
But the problem is one layer deeper:
Bad if they use the feature a lot. Bad if they don't. Not great, Bob.
Obviously the intro to this post was autobiographical. Our simple pricing was a pain in the ass. Self-service customers with different use cases thought it was expensive, and sales was having to create bespoke, per-SKU contracts for customers anyway.
It was the worst of all worlds. A critical failure for a devtool company is to get the perception that you're premium or expensive. "Oh yeah, they're great, but I'm just a startup so it doesn't make sense for me" is a kick in the gut for a company that wants to support and grow with startups.
We ended up spending over a year focused on pricing. A cross-functional team from accounting to engineering benchmarked true costs at every layer of our infrastructure, then made as many optimizations as possible. Everything from "how do we do this cheaper" to "what should we unbundle." The goal: break apart pricing to remove subsidies and make common use cases cheaper.
It's way more SKUs than we had before, but we think it's striking the right balance. Customers that need to can understand it, their usage scales with our underlying costs, and we can confidently give them the best possible price.
Some of our features were "free" before, but forced us to keep our base prices artificially high to support them. Breaking apart features like that meant customers that don't need a feature pay less, and folks that do pay roughly the same as they were paying before.
We also added plans that allow folks at lower scale to pre-purchase credits to get up and running. Yes, these are very obviously subsidized since we're explicitly letting people pay to get a lot more credits than they paid for, but the goal there is progressive disclosure of complexity.
Coming all the way back around to it, pricing complex infrastructure is complex. The goal is to make sure folks only need to think about the complexity when they care about it. If you think you'll be using more than $20, but you don't know how yet, you can lock in $20 and think about it more as you start using more of those credits.
Importantly, though, we try to be extremely explicit about what we're providing. $X gets you $Y in usage, and after $Y you're billed at our normal rates. It's rare that customers on plans go into surprise overages, but we try to be proactive and reach out if anyone's en route to a bigger bill for the first time. Surprises are the worst for everyone involved.
Because you're probably thinking it, yes, we're also working on billing caps to allow folks to explicitly say "I'd rather my video stop working than pay more than $X in a month" a la the old VPS providers of yore. There will be a different blog post talking about how that's a harder product feature to get right than you may think, but it's coming soon.
Well before we started publicly breaking apart our pricing, we were already doing it for large contracts, and boy was it a mess. Each SKU had its own commitment tied to it, which meant a massive headache for everyone. Needing to have both our sales team and the customer try to estimate how much of each individual thing the customer would use was pain at every part of the relationship, from negotiation, to overages, to renewals. Bad. Don't do that.
We migrated to a dollar-based commitment. Your annual contract is $N per year, with 720p delivery at 0.X price and 1080p delivery at 0.Y price. Use your bucket of money however you want, and if you go over there's an agreed-upon unit price rather than a penalty for success.
"Simple" pricing in infrastructure is often expensive pricing, you just don't know it yet. The simplicity is in the marketing, not the economics.
Usage-based pricing might require more work upfront: estimating usage, running calculators, understanding unit costs. But that complexity is honest complexity. It's the real economics of infrastructure.
When you're choosing infrastructure, don't just look at the pricing page. Look at the model and ask who's paying when you succeed.
Sometimes the "complicated" option is the one that makes the most sense.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。