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.
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.
Simple is subsidized
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:
- Price for the average user, not the heavy one. Set a flat rate that covers costs for someone using 10-20% of what "unlimited" theoretically means.
- Bank on most users underutilizing. The model only works if the vast majority of customers use far less than they're paying for. The gym membership business model, applied to API calls.
- Deal with outliers through...conversations. When a customer actually uses the "unlimited" product at real scale, they get a friendly call from sales explaining that they need to move to an "enterprise" plan.
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.
"Unlimited"
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).
We didn't make the "unlimited" mistake, but subsidies bit us
Our core pricing unit for Video is a minute of video content, which scales naturally with costs.
- A 1 minute video is cheaper to encode than a 60 minute video
- Delivering 200k minutes of video is cheaper than 2 million minutes
- Keeping 100 minutes of video in storage is cheaper than 500 minutes
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.
The lose-lose
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:
- If they use the feature, it's good for them because they're getting more value, but we start losing money on them. Bad for us.
- If they don't use the feature, they're over-paying. We could have given them a lower price if we knew they weren't going to use it. Kind of good for us short-term, but long-term it's a bad relationship because they'll eventually find a cheaper alternative.
Bad if they use the feature a lot. Bad if they don't. Not great, Bob.
What happened to our simple pricing
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.
Some real-world examples of where we landed
- Static renditions (MP4s) are not bundled. Storing MP4 files is expensive. We do crazy stuff with video, including only creating different versions of a video when they're requested. That lets us only store one version of a video long-term... except for MP4s, which we need to generate and store alongside the source. Breaking this out meant storage got cheaper for most of our customers.
- Auto-generated captions are bundled. We did the math and the incremental cost is small enough that it's not going to make a meaningful difference.
- Rendition tiers. Encoding, storage, and delivery are all broken out by resolution: ≤720p, ≤1080p, ≤2k, ≤4k. More complex, but simple enough to understand and predict.
- Auto-scaling tiers. As you scale within each tier, you get a lower per-unit price automatically. New customers always want to know what things will cost as they grow. This is transparent and automatic. If you go beyond these tiers, we can talk about an annual contract which means locking in a lower per-unit prices plus a few more bells and whistles (dedicated support, custom SLAs, that kind of thing).
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.
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.
As an aside: just use dollars
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.
Fin
"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.
