How to add video to your product

In Part 1 we followed one file through the six stages every video product runs: ingest, encode, package, deliver, play, and measure. You need all of that the moment you have a real audience. The only question left is who builds and runs it, and there are three answers: embed a free host, build it yourself, or use a video API. Each has a place. This guide gives you the honest pros and cons of all three, a one-look scorecard, and a decision tree, so you can pick without re-evaluating in six months.

One example, any product. We keep using an online course as the running example, but this decision is the same whether you are adding video to a marketplace, a fitness app, a media service, or internal training. Read learner as user or viewer throughout.

Option 1: Embed a free host like YouTube or Vimeo

Embedding means letting a third-party service host and play the video, and dropping its player into your product. It is the fastest way to get a video onto a page.

Where it wins

Fast and free to start. There is almost no development work, so you can test whether your audience wants video before spending a single engineering sprint. If video is an experiment, this is the sensible first move.

Great for public, top-of-funnel video. A marketing clip, a free sample lesson, a launch trailer, anything you want the whole internet to find, is exactly what a free host is built for. Credit where it is due: it is the best free video hosting there is.

Where it hurts

It is not your brand or your experience. An embed carries the host's chrome and logo, so the moment a user is inside your paid product the player reminds them they could be somewhere else. You do not control the look, the controls, or the quality bar.

Ads and recommendations pull users away. Free hosts surround your video with ads and "recommended" clips that lead users out of your product and into whatever the algorithm serves next, and they run on ad revenue, which sits badly under a fixed subscription or course fee.

No real protection for paid content. Unlisted links are not security. Teams have watched users copy an unlisted link, download every video, and repost the lot, with no recourse. If people pay for the video, embedding is the wrong home for it.

You fly blind on the data. You get basic view counts and nothing that matters: not where users drop off, not what they replay, not whether the experience was smooth. That data belongs to the host, not to you, so you cannot act on it or build features from it.

You cannot build on it. If your goal is user-generated video, users uploading and publishing their own content, embedding does not get you there. As the saying goes, you cannot build your own YouTube on YouTube.

Option 2: Build the pipeline yourself (DIY)

The do-it-yourself route means assembling the six stages from cloud building blocks, usually on something like AWS, and running the result. Your team selects and stitches every component.

Where it wins

Total control and customization. You build exactly the pipeline you want and nothing you do not, down to the last encoding setting and the last pixel of the player. Nobody else's defaults apply.

You own every part. The infrastructure, the data, and the roadmap are yours, once you have built them. For a company whose product *is* video, that ownership is the whole point.

Where it hurts

Slow to market, and never really finished. Of the three, building in-house takes the most time, commonly six to twelve months and one or two specialist hires before the first video streams, and the work does not stop at launch. Every new device, codec and browser update is more of it.

The maintenance tax never stops. The pipeline needs constant attention as the world changes underneath it, and this is where a surprising share of a team's engineering velocity quietly goes, quarter after quarter.

Owning the data is a whole platform in itself. This is the one most teams badly underestimate. To get the numbers from Part 1 you have to build capture into every surface you support, a web player, an iOS app, an Android app, and then a pipeline behind it that dedupes beacons, stitches events into sessions, enriches each view with geolocation and device detail, computes quality scores, and stores it all at scale. None of that arrives automatically. It is a dedicated team's ongoing job. "You own the data" is true, but only after you have built and continuously staffed the data platform that produces it.

Video becomes a distraction from your core product. Every hour spent keeping the video plumbing alive is an hour not spent on the thing users actually chose you for. Online video is a deep field, and keeping pace with it is a long-term commitment.

The hidden costs are the ones that bite. Beyond servers there is egress, per-request fees, cross-region transfer, and simple misconfiguration. One real example: a team ran the same encoding settings for five years, quietly paying for oversized renditions that did nothing for quality, and found it only in an audit. A la carte cloud pricing does not warn you.

When building it yourself is the right call. DIY makes sense if video infrastructure is truly your product, or you have a hard constraint like a custom codec, sub-second interactive latency, or a data-residency rule a managed service cannot meet. For every other product, the months, the maintenance, and the data platform outweigh the control.

Option 3: Use a video API

A video API hands you the whole six-stage pipeline as a service. You send a file up and get back a video that plays everywhere, and you keep your own product around it.

Where it wins

Fast time to market. Because the hard parts are already built, a first upload can be streaming the same day, often within about thirty minutes of setup, instead of a two-quarter build.

Control without the build. You get the balance embedding cannot: your player, your brand, your user experience, and your workflow, sitting on infrastructure you did not have to build.

Maintenance is handled for you. New codecs, new devices, and new streaming standards are absorbed upstream at no extra work on your side, so the maintenance tax that haunts DIY simply is not yours.

The data is captured, enriched, and yours. A video API captures every view across web, iOS and Android, enriches it with geolocation, device and quality scores, and hands it back as first-party data you own, the raw material behind a retention graph or a per-user analytics view. You get the ownership of DIY without building the data platform behind it.

Support and docs come with it. The documentation, the SDKs, and a support team are the provider's job, not another thing your team builds and maintains.

It scales with you. Traffic spikes are the platform's problem, not a 2 a.m. capacity scramble.

Where it hurts

It costs money. A video API is a paid service. Most teams find the metered cost is small next to the salaries, months, and hidden bills of building the same thing, but it is a real line item, so understand your usage first.

It assumes a developer. A video API is built for teams that can make a few API calls to integrate it. If you have no development resource at all, an embed is the more honest fit until you do.

So what actually is a video API?

Since the term gets used loosely, it is worth pinning down. A video API is a service you call to add video to your product without building the pipeline. There are three flavours you will see, and the difference is how much they hide.

A video streaming API gives you the core pipeline, encoding, storage, and delivery, and lets you bring your own player, content management, and analytics. It is the flexible middle: the backend as a service, the front end yours. FastPix is one of these. A video platform, or OVP (online video platform), bundles everything including a fixed player and a content-management system, which is convenient but ties you to one provider's models and creates more lock-in. A player API is the front-end piece only, the component that renders video on a device. Most products that want their own experience choose a streaming API, because it gives control without a full-stack commitment. If any of these terms is new, the glossary and our fuller what is a video API guide go deeper.

Making the decision

Every company is becoming a video company, so this is less "if" than "how". Line the three up against what you actually have: your time-to-market pressure, your appetite for maintenance, whether you have developers, and whether the data and experience need to be yours. Embed to test an idea with no team. Build it yourself only if video is the product. For the large middle, a product that is not a video company but wants video that is fast, branded, owned, and measured, a video API is the road, and choosing it now saves re-choosing it later.

What this looks like on FastPix

Concretely, the six stages become a couple of calls. You upload a file, and a webhook tells you when it is ready to play:

POST /on-demand   { "input": "https://.../lecture.mp4" }
   -> { "id": "abc123", "status": "processing" }

# minutes later:  { "type": "video.ready", "id": "abc123" }

<fastpix-player playback-id="abc123"></fastpix-player>

With Video on Demand, ingest, encoding, packaging, storage, and delivery are that one API. The FastPix Player handles adaptive bitrate, the auto-quality switching from Part 1, plus captions and your branding on every device, or you keep the player you have. Video Data gives you the quality and per-user engagement numbers as first-party data. Live Streaming covers real-time classes and turns the recording into an on-demand video automatically. And because the video is now something your product can read, not just play, In-Video AI adds transcripts, chapters, search, and the raw material for quizzes, the shift covered in how video and video APIs are changing in the AI era. One API, one bill per minute, your brand, your data. See pricing and the benchmark to model your own case.

None of this makes a dull video worth watching. Infrastructure does not teach, entertain, or write your product; a video API will not hold a user's attention where the content does not. What it removes is everything between good content and the user: the encoding, the buffering, the device spread, the piracy risk, and the blindness about what your users actually did. That was never the part you wanted to build.

So when the founder asks "how hard is this?", you have the real answer. Adding video is hard if you build the pipeline, quick if you rent it, and a poor experience if you borrow someone else's. Pick the road that fits. Send a file up. Get a play button back. Watch what your users do with it.