Web player development

Do not write your own player

We will start with the recommendation, because a lot of proposals get this wrong and it is the largest line item on the page.

Almost nobody should build a browser video player. Shaka Player, dash.js and hls.js exist, are maintained, and already solve adaptive bitrate switching, buffering heuristics, manifest parsing and DRM licence exchange. Commercial players add multi-DRM packaging, support contracts and a roadmap.

What you would be taking on by writing your own is not a sprint. It is buffering behaviour tuned against real networks, ABR decisions that do not oscillate, quirks across a dozen browser versions, and a permanent maintenance obligation as those browsers change underneath you. That work has no ceiling and no finish line, and none of it is your product.

There are real cases for custom player work, and they are narrower than they sound:

• A playback behaviour genuinely specific to your product that no player exposes — a bespoke multi-view layout, an unusual live interaction model.
• A licensing or cost constraint that rules out commercial players and requires heavy modification of an open-source one.
• A performance target on constrained hardware where a general-purpose player's feature set is the problem.

Everything else is integration. Build the application around a player; do not build the player. If a proposal in front of you quotes a custom player as standard, ask what it does that Shaka does not.

One honest qualification, because integrating is cheaper rather than free. Players move too. Shaka Player removed IE11 support at version 4.0, and its changelog records a breaking change in February 2026 requiring applications to call updateStartTime where previous behaviour differed; a major version 5 now exists. So you still own an upgrade treadmill — it is simply a far shorter one than maintaining buffering heuristics yourself, and someone else does the hard part. Budget a maintenance allowance rather than assuming integration is a one-off.

Streaming web app development for vod platforms is where this matters most, because a catalogue business has genuinely hard problems — merchandising, entitlement, recommendations — and none of them are in the player.

Browser DRM is where the web gets genuinely hard

If the player is the part you should not build, DRM is the part that is harder than it looks.

Browser DRM runs through Encrypted Media Extensions, the web API that controls playback of content subject to a rights-management scheme. Decryption is handled by a Content Decryption Module in the browser, and your application negotiates with it rather than decrypting anything itself. Encrypted Media Extensions has been available across browsers since March 2019.

Two things follow that catch teams out.

You need more than one key system. The systems in play are Widevine (com.widevine.alpha), PlayReady (com.microsoft.playready), FairPlay, and Clear Key (org.w3.clearkey) for unprotected testing. Different browsers ship different ones.

The engineering answer is not a hardcoded browser-to-DRM lookup table. Shaka Player is key-system-agnostic: its documentation states it does not prefer any key system over any other, and that it uses Encrypted Media Extensions to query browser capabilities rather than making assumptions about specific platforms. That is the correct pattern, and it is more robust than the browser-detection tables that circulate in blog posts.

Encrypted Media Extensions requires a secure context. HTTPS, or localhost. Shaka Player's documentation notes that this requires a secure URL, that Chrome enforces it today, and that other browsers are expected to follow. If your staging environment is served over plain HTTP, protected playback will not work there — which is a confusing morning for a team that has just integrated DRM correctly.

And Encrypted Media Extensions is itself optional. It is defined as an optional extension to HTML, so a browser can be entirely HTML-compliant without implementing it — and a browser lacking it cannot play encrypted media at all. That is not a gap you code around; it is a browser you decide whether to support.

Streaming web app development for broadcasters usually arrives with the DRM question already answered by an existing licensing arrangement, which makes the web build a question of matching what the licence server already speaks.

Get an HTTPS staging environment before you integrate DRM. It costs nothing and removes an entire category of false failure from the first playback sprint.

No store is the real advantage

It is worth naming what the web gives you, because it is the thing the rest of this cluster spends its pages working around.

• Samsung publishes no certification duration at all.
• Google Play refers to up to 7 days, or longer in exceptional cases.
• Roku tells you to expect feedback within a week if further testing is needed.
• Apple is fastest, at 90% of submissions reviewed in under 24 hours.

The web has none of this. You deploy. A bug found at 10am is fixed for every viewer by lunchtime, with no resubmission and no version fragmentation, because everyone is on the build you just shipped.

That has a strategic consequence worth acting on: the web is the cheapest place to be wrong. Settle your catalogue model, your entitlement rules, your playback behaviour and your analytics here, where iterating is free, and let the platforms with review queues inherit decisions that are already proven.

What the web does not give you

One honest limit, because the freedom above is not total.

You trade a gatekeeper for a matrix. Browsers vary in codec support, DRM key system, autoplay policy and fullscreen behaviour, and they update continuously rather than on a model-year cadence. There is no certification to fail, so nothing external tells you when a browser update broke your player — your viewers do.

That makes automated playback testing worth more on the web than anywhere else, and it is a real cost that a naive estimate leaves out because "it is just a website".

What carries over to the rest of the rollout

The honest split, if the web is your first build:

Carries over. Your API layer, entitlement model and catalogue metadata, to every platform. Your design system as specification. Your playback configuration and DRM licence server. To Samsung Tizen and LG webOS specifically — both of which run web apps — your language and much of your application logic.

Does not. The interface, once a remote replaces the pointer. Your performance assumptions, because a television has a fraction of a laptop's headroom. And the player integration itself, because TV platforms expose their own media APIs rather than the browser's.

Streaming web app development for media companies is often scoped as the last item when it should be the first, precisely because everything above flows outward from it.

What drives the cost

A range that fits everyone helps nobody, so here is what actually sets the number.

1. Whether DRM is in scope. An unprotected catalogue is a different project from a multi-DRM one.
2. Which player you integrate. Commercial players carry licence fees and remove work; open-source players are free and move that work to you.
3. The breadth of your browser support. Every additional legacy browser is testing surface.
4. Whether smart TVs follow. If Tizen and webOS are coming, the web app should be architected for that from the start.

Tell us those four and you get a real number rather than a range that covers everyone.

Who builds it

Everything above is how we actually work rather than a checklist assembled for this page.

We build our own tooling. VibeView came out of exactly this problem — shipping to every platform means testing on every platform — and on the web that means playback verified across browsers rather than assumed from a version table. When a project needs middleware rather than only an app, MwareTV is a technology partner of ours, so both sides come from one conversation.

And the people who scope your project are the people who build it. There is no account layer between you and the engineer who will tell you not to build a player.

Where the web sits in the rest of your rollout

First, in most cases. It is the fastest surface to ship, the cheapest to change, and the one where the decisions that bind every other platform get made.

Build it as though Tizen and webOS are coming — because they usually are, they are web apps too, and the difference between a shared codebase and a rewrite is a decision made at the beginning rather than discovered later.

We build these, end to end

The web app, player integration and configuration, multi-DRM through EME, the entitlement and catalogue layer that the rest of your platforms will reuse, and cross-browser playback testing.

If a proposal in front of you includes building a custom video player, we will tell you honestly whether your case is one of the few that warrants it. Usually it is not, and that conversation saves more money than anything else on this page.

Send us your DRM requirements, whether you have a player licence already, and the platforms you expect to be on in two years. You will get back a scope and a number rather than a brochure.