You Probably Don't Need Streaming

When you ask how to add video to an app, the advice almost always jumps straight to HLS or DASH. Adaptive bitrate. Segments. Playlists. Player libraries. A full media pipeline.

Sometimes that's the right call. Often it isn't.

For a lot of applications, serving optimized video files is simpler, cheaper, and performs just as well. The problem is that file-based delivery gets dismissed as "naive" when in reality it covers the majority of real-world use cases.

Here's how to tell which one you actually need.

Streaming formats exist to solve a specific set of problems:

They work by chopping video into small segments, encoding multiple renditions at different quality levels, and letting the player switch between them as conditions change.

That machinery is genuinely useful when you need it. It's also expensive, both technically and operationally, when you don't.

A lot of application video looks nothing like what streaming was designed for.

If your app includes any of these, you almost certainly don't need streaming:

In these cases, progressive download works extremely well. Modern browsers buffer intelligently, handle seeking, and start playback before the full file has downloaded. Users don't experience this as "downloading a file." They experience it as video playback.

The distinction matters because streaming is often adopted not because the product demands it, but because it feels like the correct architecture.

File-based delivery doesn't mean dumping raw uploads into a storage bucket and hoping for the best.

Done correctly, it means:

When you get this right, playback starts fast, seeking works, and buffering is predictable. For short-to-medium videos, the user experience is effectively indistinguishable from streaming.

Streaming is often pitched as "handled by the platform," but that doesn't make it free. You're opting into:

None of that is inherently bad. It's just rarely necessary early on, and it compounds. Every layer you add is a layer you'll eventually debug at 11pm when a user reports playback is broken on their device.

The question isn't whether streaming is a good technology. It is. The question is whether your product actually needs it.

You probably need streaming if:

If neither is true, start with file-based delivery.

It's easier to move from files to streaming later than the other way around. Premature streaming is just over-engineering with extra steps.

Optimized files behind a CDN handle most application video well. Use streaming when the problem actually calls for it.

Say you're building a SaaS product. You have 30 onboarding videos, each 2 to 4 minutes long. Users watch them once, maybe twice. Nobody scrubs. Nobody watches on a train with spotty LTE.

You pick a video streaming API because it looks professional and the docs are good. Here's what that decision actually costs you:

Storage and delivery: Even where encoding is bundled or free, every extra rendition is something you store and deliver. Storage and bandwidth are billed on all of them — and on platforms that do charge for encoding (AWS MediaConvert, Mux), it's billed on output minutes, so multi-rendition multiplies it fast.

The player SDK: Video streaming APIs typically bundle analytics and a proprietary player. You add the dependency, wire up the analytics, handle the initialization logic. It's not hard, but it's not zero either. Now your video playback is coupled to a third-party player with its own quirks, update cycle, and browser edge cases to debug.

HLS overhead: Every video gets segmented into a playlist of .ts files. Storage isn't just one file per resolution — it's hundreds of small chunks. That's fine when you need adaptive bitrate switching. For a 3-minute onboarding video on a desktop browser, it's just complexity your team carries — player quirks, more surfaces to debug, and vendor lock-in — for no real gain.

The alternative: transcode to MP4, serve behind a CDN, use a native <video> tag. Your 30 onboarding videos load fast, seek cleanly, and cost a fraction of the pipeline. No player SDK. No per-minute encoding bill. No .m3u8 playlists to reason about when something breaks.

The streaming infrastructure didn't solve a problem your product had. It just created new ones.

Usually not. If your app serves clips, demos, course content, or UGC with known lengths, optimized MP4 files behind a CDN are often enough. HLS and DASH matter more when you need adaptive bitrate switching, live playback, or very unreliable network conditions.

Progressive download is standard file delivery where the browser starts playback before the full file is downloaded. For short to medium videos, users experience it as normal playback, especially when the file is optimized and served through a CDN.

Streaming makes sense when videos are long, users scrub around a lot, or network conditions vary enough that adaptive bitrate matters. It is also the right choice for live or near-live video, where file-based delivery cannot keep up.

Optimized MP4s perform well because the file is encoded for web playback, delivered from a CDN, and sized for the use case. That keeps startup fast, buffering predictable, and the implementation much simpler than a full streaming pipeline.

Yes. It is much easier to start with file-based delivery and add streaming later if the product truly needs it. That avoids over-engineering early and gives you a cleaner baseline when usage grows.