P.S. If you want more serverless and infrastructure-cost workflows like this one delivered to your inbox every week, join 800+ indie hackers getting them free: *https://wuki.beehiiv.com/subscribe*.
Last year I made a decision that most developers would call financial malpractice: I stopped renting video servers and started paying for compute the way I pay for electricity.
Per second.
No monthly minimums. No "you're on the Hobby plan, your 4K job just took 90 minutes to start." Just a counter that ticks while a job actually runs, and stops the moment it's done. After 10,000 serverless video jobs, the data is in. Here's what encoding actually costs, where the money really goes, and why I think the entire "per-minute" pricing model in video infrastructure is quietly broken.
The problem I started with
I run several products that need video processing: clips trimmed, subtitles burned in, formats converted, thumbnails extracted, audio stripped. The boring, life-destroying 95% of video work that no one writes blog posts about.
The first version used a standard VPS setup. A beefy $90/month box with a GPU, FFmpeg pre-installed, and a queue manager I wrote myself. It worked — kind of. Then traffic doubled, and the box became the bottleneck. Upgrade to a $400/month box. Then a weird job would spike memory and take everything else down with it. The classic horror.
What I actually needed wasn't a bigger box. It was a pricing model where the user pays for exactly what their job consumes — and where my costs align with their usage, not with my worst-case provisioning guess.
How I measured the real cost
I built ffmpego.com — a serverless FFmpeg API — and instrumented every single job. After 10,000 of them, three patterns jumped out that I did not expect.
1. Most encoding work is small. Like, embarrassingly small.
The median job on the platform is under 60 seconds of compute. Trimming, thumbnailing, format-shifting — most of it finishes in seconds. The "average video job" in developer imagination is a 4K render farm. In reality it's a 15-second MP4-to-GIF conversion.
Yet almost every video API on the market is priced per minute of video processed or per gigabyte transferred, which means a 15-second job gets billed the same as a 15-minute one. If you're doing lots of small work, you are massively overpaying — and your provider's margins are mostly you.
2. The cost curve is brutal on the tail.
20% of jobs account for ~80% of total compute seconds. Long renders, dense filters, high-res encodes — they chew through seconds the way your laptop fan chews through battery. This matters because of what happens on the other side of that tail: failures.
3. Failed jobs are the hidden tax.
This is the number nobody talks about. When a video job fails — and plenty do: corrupt input, exotic codec, a filter graph that FFmpeg just refuses to parse — most platforms still bill for the work already done, because they bill per minute of video or per hour of wall-clock usage.
On a per-minute model, a 20-minute render that fails at minute 19 costs the user 20 minutes of billing. On a per-compute-second model, it costs the 10 seconds it actually ran before dying. Failed encodes should never be billed. That's not a feature, it's basic fairness — and it's one of those honesty-mechanisms that costs you real revenue in the beginning and builds real trust in the long run.
What the data showed about pricing
Here's the table I wish I'd had before building anything:
| Job type | Real compute | Typical "per-minute video" price | Fair price at $0.0036/sec |
|---|---|---|---|
| 15s trim (MP4→MP4) | ~4 seconds | $0.06 (min bill) | $0.014 |
| 60s clip + subtitles burned in | ~28 seconds | $0.18 | $0.10 |
| 10-min 1080p transcode | ~95 seconds | $1.80 | $0.34 |
| 4K HLS segmenting, 30-min video | ~6-8 minutes | $5.40 | $1.30-1.70 |
| Failed render | 0 billable | full price | $0.00 |
The pattern is consistent: users are paying 3-5x more than the compute actually costs on traditional models, mostly because the middlemen (bandwidth, storage, startup overhead) get bundled into "minutes of video." The compute itself is cheap. The friction is not.
The design decision that changed everything
Three decisions made the difference between this being a toy and being useful:
Compute-second billing. Bill only when a job is actually running. An IDLE queue, a waiting job, a stalled connection — none of it should bleed the user. This is what "serverless" was supposed to mean all along: you pay for the moment you use, not the period you rent.
Hard monthly caps. No surprise invoices. Every plan has a ceiling; when you hit it, the platform tells you to wait until next month rather than auto-billing you into debt. For a solo developer's side project, a runaway encode bill is a genuinely frightening experience. It shouldn't happen.
Failed jobs are free. If the process exits non-zero, the user pays nothing. It took me a while to see how much trust this buys. Developers have been burned by video APIs before — opaque pricing, hidden charges, "infrastructure fees." Being the API that says "if it didn't work, it's free" is a differentiator that no amount of marketing can fake.
What I'd do differently
Honestly? I'd have started serverless-first. I spent months tuning my own VPS queue — installing, hardening, babysitting — for a workload that belongs in a short-lived container. If I were advising my past self: build the wrapper API first, put compute-behind-an-endpoint second, and treat every failure as a pricing question rather than an ops question.
I'd also have instrumented billing from day one. I didn't measure job-level cost per customer for the first ~1,500 jobs, and that means there's a chunk of early data I can never get back. If you're building anything usage-based: log duration, cost, and outcome on every single request from day one.
The bottom line
Video encoding is not expensive. Renting video infrastructure is expensive. The compute for a typical job costs fractions of a cent; the platform around it — the queueing, the retries, the honest billing — is where the value lives.
I built ffmpego.com to prove that model: a serverless FFmpeg API billed by compute seconds (from $0.0036/sec), where failed encodes are never billed and hard monthly caps mean no surprise invoices. 10,000 jobs in, the data holds up: pay for what you use, and both sides win.
What's your experience with video processing costs? If you've hit a surprising encoding bill — or you're running a usage-based API yourself — I'd love to hear how you handle pricing and failure. I'm still figuring out the right tradeoffs, and the comment section here has taught me more than any pricing course ever did.
Top comments (0)