Most buyers pick a Video API vendor on features. The pricing model is what they get stuck with.
Here's something that takes place quite often. You launch a WebRTC POC. Doesn't cost you much. If you're successful? It quickly climbs to $5,000 a month on your Video API platform of choice. Then it explodes. You find yourself 9 months later at $80,000 a month or more.
The product hasn't changed at all. It is the same.
The costs pile up because you're paying by the minute 🙀
Are there any alternatives for that? Have you picked the wrong vendor? The wrong pricing model? The wrong something?
Should you just go and build on your own instead of buying into someone else's WebRTC infrastructure?
Let's dive into the fascinating world of Video API pricing and WebRTC costs.
What I am ignoring here
Before I begin though, know this:
Figuring out which WebRTC vendor to use isn't only an issue of pricing.
Pricing for me comes last. After you figured out and locked down all other KPIs in your vendor selection process. You start with your requirements, find a suitable fit, and then look at pricing to align with your own business plan and cost structure.
Why am I jumping straight to pricing? Because most of the time I am in the weeds of technology, features, benefits, requirements. The pricing piece I do with clients. Time to shed some light about this topic. Especially now, when I am deep in work on my upcoming update of the Video API report (and yes, consider this a sales plug 😉)
Pricing isn't only about costs and vendors
How much does a video minute cost? ~$0.004
Across vendors, that's going to be the price point. It will fluctuate and vary a lot - depending on features.
But that's only one out of 4 different business models you can choose from when using managed Video API vendors.
My suggestion? Start by deciding on the model before going for vendor pricing.
Pricing model matters more
Most WebRTC cost conversations start with per minute costs. It makes sense - most vendors offer per minute cost and that's how the industry is geared.
Why? Because doing per GB complicates the calculation for the developers when doing their estimates. And in some ways, it ends up costing less as well - at least in the instances when it is available.
The reason this is so is on one hand to simplify the calculation for the developers - the customers - we do want them to buy our Video API infrastructure. So we do per minute and not per GB. On the other hand, it is hard to do per seat per month or similar models - because it makes it hard for us, the Video API vendor, to match our own cost structure with our expected revenue.
That said, there are those who do offer other pricing models than per minute costs. And at times, based on your use case and scenario - these may be a benefit from costing perspective for you as a buyer.
When the costs are sky high - you may end up building the infrastructure on your own. But when it isn't, figuring out the alternative pricing models after striking out the vendors that don't fit your product requirements is the next step to take. It is at least what I'd do.
Video API pricing models
Let's see what the main pricing models are. I've alluded to them earlier: per minute, per MAU, per GB and build:
Per-minute per-participant: the dominant model
Most of the vendors and most of their clients end up with the per minute pricing.
The math is "simple" - you pay participants x minutes x rate - the number of participants in a meeting, multiplied by their minutes, multiplied by the rate per minute.
For most vendors out there, the number is ~$0.004 per video minute. It will oscillate a bit between 0.0041 and 0.00399 - but who's counting? (if you come with lots of minutes, they will discount it for you anyways)
What does that $0.004/min get you?
- HD video. Typically at 720p. 1080p streams and higher sometimes cost more
- TURN relay is included (yay)
- SDKs across all browsers, devices and platforms supported by the vendor
- Client side AI fairy dust - basic noise suppression and virtual backgrounds
Complexity comes in when you want something different. Here's what you'll find with different vendors:
- Voice-only can be 4x cheaper with the right vendor
- Going for 1080p resolution can cost you 2x more
- High publisher counts can cost more on some vendors
What's never included and you may want to factor in when you do pricing estimates:
- Fixed monthly add-ons: HIPAA BAA, advanced analytics, Enterprise SLA, ...
- Per minute add-ons: Real-time transcription, advanced noise suppression, Voice AI stacking on top of it, PSTN support, ...
Yes. A basic video minute costs $0.004. I bet you don't think your application is basic. Its pricing likely isn't going to be either.
Per-MAU: the niche
There's only one Video API vendor offering per MAU pricing and that's 8x8 JaaS.
Why only 8x8 and no one else? Who knows?
It might be because 8x8 sells UCaaS as well, and there per-MAU is the bread and butter price plan. It might be a differentiator that was decided upon.
Whatever the reason, it gives price predictability that is nowhere else in the industry. It fits nicely where your application has "known" users - they aren't random users. In such a case, more sessions done by the users doesn't cost you more.
The more sessions users have on average, the more a per MAU pricing model will be attractive to you compared to the alternatives.
One thing to mention - some vendors do have MAU pricing for messaging - but not for video calling. That's simply because an hour of a video call likely costs more to operate than a month full of messages - especially when bandwidth pricing is so high.
Per-GB: same capability; different effort
There is an option to pay per GB - per bandwidth. This is similar to per-minute since it is per use, but different because it is more complex for you as the developer to estimate.
Cloudflare offers both per minute and per GB. Their Realtime SFU is per GB. Their RealtimeKit is per minute.
To use the SFU? They require you to be a WebRTC expert. For RealtimeKit? No WebRTC expertise is needed.
Same WebRTC infrastructure. Two different pricing models and customer types.
Other vendors offer per GB pricing at high scale - you can look at it as a different pricing model - or simply a discount tactic. Up to you to frame it the way you see it.
Build: different cost structure, more headaches
You can build the WebRTC infrastructure on your own. Not go with a managed Video API vendor. Pricing won't be per minute. It will be based on compute, memory, storage, bandwidth - the things that make IaaS... well... IaaS.
I'll start with the bottom line here: Build isn't going to be cheaper
At least not in the first year.
What developing on your own does is replacing the variable cost of the vendor's margin with your engineering, compliance and AWS fixed costs.
Do your research here, but be totally honest with yourself.
Things you should include here:
- Engineering - the developers (WebRTC skill is expensive)
- Compliance and dev ops
- Ongoing maintenance and optimization work, after launch
- Infrastructure costs
If you're below 1,500-2,000 concurrent users on average - you're likely paying more on the build path than the buy from a vendor path.
Per-minute is where the industry is today
The Video API report I am updating is an interesting checkpoint here. From one edition to another, I can see trends shaping up.
Last year, LiveKit was on per-GB front and center in their pricing model. Today? They're doing per-GB as an overage.
Cloudflare, pre-acquisition of Dyte, was per-GB. Post-acquisition, with the introduction of RealtimeKit, is hammering the per-minute pricing drums as loud as everyone else.
There are tiering discounts, monthly commit discounts, bundled pricing and more. The dominant though is per-minute.
This isn't an accident. Per-minute scales with you AND with the vendor's costs simultaneously. It makes for a defensible model in a competitive market:
- Buyers can model it on the back of a napkin
- Vendors can margin it
- AI add-ons stack cleanly on top (or gobble the per-minute pricing without even noticing)
Per-GB lives one layer underneath for buyers who want to do more of the work themselves. They are those who are likely to churn and build on their own anyways. So why sweat it out to attract them?
How to decide
How do you figure out which pricing model fits you?
Start with what scales in your product. Sessions and minutes? Users? Bandwidth? Or are you at the kind of scale where fixed cost is the better trade?
Match that to a pricing model. Then pick the vendor inside it. The vendor matrix has its own headaches - that's what the Video API report is for - but the model question comes first.
A few examples to make it concrete:
- Consumer 1:1 video app with bursty usage? Per-minute. Maybe even build on your own if it is only peer-to-peer without an SFU. Then pick whichever vendor lands cheapest on your feature mix
- B2B SaaS with a bounded user base and long sessions? Per-MAU if usage is heavy. Per-minute if it's light
- High-scale platform with WebRTC expertise on the team? Per-GB or build. Likely build. Run the crossover math from the report
The hard part isn't the framework. It's being honest with yourself about which shape your product actually is.
The Video API Report
Back to that Video API report of mine...
I am in the process of writing it. Reviewing what needs to be added, removed. Frankly? At the moment, it feels and seems like a complete rewrite. Or almost.
The report has the full per-vendor pricing matrix, the build-vs-buy calculator, and the named-vendor decision view. It is chock full with other important content for those who need to decide which vendor to pick (or if to pick a vendor at all) - and also for the vendors themselves - to understand where they stand in the market.
I tried here to share with you the framework I am using for pricing. A glimpse of it. The report gives you the numbers and the matrix.
The report is here: Video API Report. The 3rd edition update is in progress. The current edition is live now. Purchasing it means you get the 3rd edition - without the planned price bump.
For ongoing pricing moves between editions, WebRTC Insights covers them as they happen - they are even more important for those on the build path. For one-on-one work on your specific vendor decision, Tsahi In Your Corner is where that work lives.
