10 Questions to Ask Before Choosing a Video Hosting Platform

Video hosting comparisons often come down to a feature list, and a feature list is a weak instrument for this decision. Two platforms can both tick "analytics", "security" and "API" and still differ completely in what you can actually do on the plan you would buy. The questions below are built to expose that difference before you commit, not after you have moved a library.

Work through them against your own workload rather than a generic one. Each question states what to ask, what evidence settles it, and the tradeoff that tends to be hidden. Ask them of every platform you are considering, including this one — the answers should come from a current page, a documented limit or a test you ran yourself, not from a sales sentence.

1. What video workflow must the platform actually support?

Write down the workflow before you look at any vendor. On-demand video, live, gated or paid access, internal-only distribution, and video inside an app you build are five different problems, and a platform can be strong at one and thin at another. A shortlist drawn up before the workflow is written down tends to be shaped by whichever pages you read first.

• Which of on-demand, live, gated and in-app playback are must-haves, and which are aspirations for later?
• Who uploads, who publishes, and who is allowed to change access — one person, or several teams with different permissions?
• Where does playback happen: your marketing site, a members area, a learning platform, a mobile app, a TV app, or several of these?
• Which of those surfaces has to work on day one of the migration, and which can follow?

Keep this list. It becomes the weighting in the scorecard at the end, and having it written down first makes it easier to notice when a demo starts re-ordering your priorities.

2. What does upload and encoding produce, and how does playback adapt?

"HD hosting" says nothing useful. What matters is what a source file becomes after processing, and what the player does with it on a connection you do not control. Adaptive streaming means several renditions are produced and the player switches between them mid-playback as conditions change; it is intended to reduce stalls rather than eliminate them, and no provider controls the network the viewer is on.

• What renditions does a source file produce, and can you influence the ladder — or is it fixed?
• Is the original source file retained, and can you get it back later? This is a migration question as much as a storage one.
• How long does processing take for a typical file of your size, and what happens when it fails?
• Which formats and codecs are accepted on ingest, and which are delivered to viewers?
• What does playback fall back to on an old device or a restrictive network?

Treat any zero-buffering or fixed-quality-everywhere claim as a flag rather than a feature. The honest version is a ladder, an adaptive player, and a test on your own worst-case connection.

3. What are the real capacity and cost units under your workload?

Price per month tells you very little on its own. Cost is decided by units: storage, number of videos, delivered bandwidth, live hours, and whatever happens when you exceed one of them. Two platforms with similar headline prices can cost quite differently for the same library once your bitrate and viewing hours are applied to those units.

Estimate delivery from your own numbers rather than a vendor example. Roughly, delivered data ≈ average bitrate × total viewing hours, so the same audience costs more when your ladder tops out higher and viewers hold the top rendition.

• What is included at each plan level: storage, video count, bandwidth, live hours, seats?
• What happens at the limit — is it an overage charge, a top-up, throttling, or a hard stop?
• Which capabilities are plan-gated rather than universally available?
• How does the price change as the library grows, versus as the audience grows? These are different curves.
• Is the pricing page generated from the live catalogue, or is it a marketing copy of it?

4. Who may watch, and where may playback occur?

These are two separate controls, and they are often confused. Access rules answer who is entitled to watch — a member, a subscriber, a purchaser, an authenticated employee. Domain restrictions answer where an embed is permitted to run: playback is intended to be refused on domains you have not approved, so a player lifted onto a site you have never heard of does not simply keep working. A platform can be strong on one and absent on the other.

• How is entitlement expressed: per video, per project or collection, per member, per plan?
• Can playback be restricted to a list of domains you control, and how are exceptions handled during development?
• Who issues playback authorisation, and where does that happen — in the browser, or on your server?
• How is access revoked, and how quickly does a revocation take effect on a session already in progress?
• If you sell access, does the platform manage entitlement, take the payment, or both — and which do you actually need?

Ask for the boundary in writing where it is decisive. "Supported" and "supported on your plan, in your configuration, for your surfaces" are not the same sentence.

5. Which protection claims are controls, and which are guarantees?

This is a question where marketing copy and technical reality often diverge. Encryption, signed URLs, DRM and watermarking are controls: they are intended to raise cost and friction for the person trying to take your content, and some of them can help attribute a leak. None of them makes copying or screen capture impossible, so treat a claim that one of them does as a reason to ask exactly what is being promised, and on what basis.

• What is encrypted, at rest and in transit, and how are playback keys issued and to whom?
• Is DRM available, on which plans, and which of the certified paths does it cover?
• What does watermarking actually overlay, and does the vendor describe it as attribution or as prevention? Ask which, in writing, and on what evidence.
• What is the honest answer to screen recording — how much friction is bought, and at what cost to legitimate viewers?
• Which protections apply to live as well as on-demand? They are frequently not the same set.

The useful conversation is proportionality: how much friction is worth buying for this content, for this audience, at this price. A vendor willing to have that conversation gives you something you can plan against; one who says the problem is solved does not.

6. What analytics are available, and at what granularity?

"Real-time analytics and insights" is a phrase, not a specification. What decides whether analytics are useful to you is granularity, retention and export: what dimensions exist, how far back the data goes, and whether you can get it out into the tools your team already uses.

• Which metrics exist — plays, watch time, completion, engagement over the timeline, delivery quality, bandwidth?
• At what granularity: per video, per project, per account, per time bucket?
• Are viewer-identifying dimensions available at all, and do you want them given your own privacy commitments?
• How long is data retained, and can you export it or query it through an API?
• How current is the data — is it live, near-live, or batched, and does the difference matter to any decision you actually make?

Decide what you would do differently with each metric before you weight it. Analytics nobody acts on are a line item rather than a capability.

7. Can the API and auth model carry your integration safely?

If video is inside your application rather than beside it, the API is the product. The coverage question is whether the operations you need exist; the safety question is where credentials live. An API key belongs on your server. Browser playback authorisation should be a signed token your server generates, not a key shipped to the client.

• Which resources have API coverage — videos, uploads, projects, channels, live streams, analytics, subscriptions, access?
• Are there webhooks for the events you need to react to, and how are retries and duplicate deliveries handled?
• How is the API authenticated, and is there a documented separation between server-side keys and browser-facing tokens?
• What are the rate limits, and what does the API do when you hit one?
• How are breaking changes versioned and announced?

Read the API reference before you buy, not after. The documentation shows you the contract your integration would be written against, which a demo does not.

8. Does live streaming cover the whole workflow, including failure?

Live is easy to under-specify, because "live streaming supported" can mean ingest and playback and little else. The workflow you actually run includes what happens before the stream, what happens to the recording afterwards, and what happens when the encoder drops mid-event.

• What ingest protocol is expected, and does it work with the encoder your team already knows?
• How do viewers watch — the same embed as on-demand, or a separate surface?
• Is scheduling available, and can you stream to more than one destination at once?
• What happens to the recording: is it retained, for how long, and does it become an on-demand asset automatically or by hand?
• Which protections apply to live, and which do not? Do not assume the on-demand set carries over.
• What is the documented behaviour when ingest drops, and what does the viewer see?
• What concurrency and latency does the platform state, and is it a documented figure or a verbal one?

If a live event is business-critical, rehearse it end to end on the platform before you sign, including a deliberate encoder failure. A rehearsal shows you the failure behaviour that a feature list does not describe.

9. Which distribution surfaces are native, and which do you build?

Websites, member areas, mobile apps, TV apps and third-party platforms are not one capability. A hosting platform typically gives you a player and an embed for the web, and structured inputs — feeds, APIs, tokens — for everything else. Those inputs are not the app. Somebody still has to build, submit and maintain a TV or mobile application, and that somebody is usually you.

• Which surfaces are genuinely native: an embed, a player SDK, a plugin for the CMS or learning platform you use?
• For TV and mobile, exactly what is supplied — a feed or an API — and what remains customer-built?
• Does a feed create, submit or list an app on any store? It does not; confirm the vendor says so plainly.
• How is the player branded, and is that branding on your plan?
• How does an embed behave inside the specific tool you will paste it into?

Cost this honestly. A supplied feed is genuinely useful and genuinely not an app, so a TV surface budgeted as "included" can leave real build work unaccounted for.

10. How will you test, migrate, operate and roll back?

This question is easy to defer, and expensive to defer. A video platform is not a one-off purchase, it is a dependency: it holds your library, it sits in your pages, and getting out of it later is work you should scope before you get in.

• Can you export your videos, metadata and source files, and by what mechanism?
• How will existing embeds be replaced, and what happens to URLs that are already in the wild?
• What is the rollback plan if the migration goes badly halfway through?
• How is support delivered, on what channels, and what is actually committed rather than implied?
• How are incidents and maintenance communicated, and is there a status page you can subscribe to?
• What contractual commitments exist in writing — availability, regions, data handling, notice periods?

Get the commitments in the contract, not in the sales thread. Anything that matters to your business should be a term you can point at later.

Turn the ten questions into a weighted scorecard

Ten questions produce ten opinions unless you weight them. Before you score any vendor, mark each question against your own workload as must-have, nice-to-have or not needed. A platform that fails a must-have is out regardless of how well it does elsewhere; a platform that fails only not-needed items is not actually worse.

Score each question 0–2: 0 if the platform does not do it, 1 if it does with a caveat you have written down, 2 if you have evidence it does it on your plan. Weight must-haves at 3, nice-to-haves at 1, and not-needed at 0. A must-have scoring 0 ends the evaluation for that vendor — do not let a strong total paper over it.

Then run a small proof with your own material

A scorecard narrows the field; a proof tests it. Before migrating anything, run a deliberately small test using your own video, your own embed target and your own access rules. It is a bounded piece of work, and it surfaces problems while they are still cheap to act on.

1. Upload a real source file — your longest and heaviest one, not a sample clip — and check what processing produces and how long it takes.
2. Embed it on a staging copy of the page it will actually live on, in the tool you actually use.
3. Watch it on the connections and devices your audience really has, including a deliberately poor one and an old device.
4. Apply the access rule you intend to use, then try to reach the video without entitlement — from a different browser, a different domain and a signed-out session.
5. Pull the analytics for that test and confirm the numbers you need exist, at the granularity you need, and can be exported.
6. If the API matters, authenticate and make the two or three calls your integration would depend on.
7. If live matters, run a rehearsal end to end, and drop the encoder halfway to see what the viewer sees.
8. Write down what you would do to undo all of it. That is your rollback plan.

Record each result in the Evidence column. At the end you will have a comparison built from things you observed rather than things you were told.

Checking these questions against DynTube

The same checklist applies here, so the useful thing this page can do is tell you where our own answers are written down rather than assert them:

• Capabilities and their stated boundaries — /features, which groups them by the question they answer.
• Plans, included units and what your money actually buys — /pricing, rendered from the live billing catalogue.
• API coverage, authentication and the server-side key boundary — /dev.
• Procedures, parameters and documented limitations — /docs.
• Anything decisive that is not written on those pages — /contact, and ask for it in writing before you commit.

If a question above matters to you and you cannot find our answer to it, that is a fair reason to ask us directly, and a fair reason to ask every other vendor on your shortlist the same way.