Developer velocity for video teams

Adding video looks like a two-week task. Then the back buffer fills, a segment returns a 403, and week three arrives. Here is where a video build really loses time, and what changes when the pipeline becomes one thing you call instead of seven you run.

A team we know shipped video in two weeks, and it worked in the demo. Three weeks after launch the tickets started: playback went choppy, but only for some viewers, and only well into a session. They had not changed a thing.

They had hit one of the quiet ones. Their web player used hls.js, the open-source engine browsers without native HLS rely on to play it, and hls.js ships with its back buffer set to unbounded. Every second a viewer watched stayed in memory. Thirty to ninety minutes into a long session, on a mid-range Android phone, the tab ran out of room and playback began to stutter. Native apps were fine. Some browsers quietly freed the memory and hid the problem entirely, which is worse, because it means it does not show up until a particular viewer on a particular device sits through a particular length of video. The fix was one parameter, once they knew. Knowing cost them a week and a rough launch.

That is what building video is actually like. Not the two weeks. The week three you did not budget for, multiplied by the number of ways video can surprise you, which is a large number.

None of this is because the team was junior. It is because "add video to the product" is not a feature request. It is a request to build and operate a small distributed system, and then to keep operating it while you try to build everything else. That is the real tax on velocity: not how fast you write the first version, but how many separate systems you have to keep correct, and how much of next quarter you will spend maintaining this one.

What "add video" actually is

Follow one upload from a phone to a viewer, and here is what sits between the two. None of it is exotic. That is the point.

You have to transcode the file into several quality versions so it plays on a subway phone and a fiber laptop; the set of versions is an encoding ladder, and choosing its rungs is its own small craft. You package those versions into short segments and write manifests, the playlist files a player reads, in both HLS (Apple's streaming format) and DASH (the open one), because devices disagree about which they speak. You store the renditions and put a CDN (a content delivery network, the global cache that keeps video near viewers) in front, plus a second one if uptime matters. You secure it with signed URLs, or with DRM (digital rights management, the studio-grade lock), which means a license server and a separate integration on every platform. You ship a player for web, iOS, Android and TV, each with its own ABR (adaptive bitrate, the logic that drops quality when the network dips) and its own quirks. And you build analytics, because "is it working" and "is anyone watching" are different questions, and both need a pipeline that turns raw playback events into startup time, rebuffering and completion.

Any good engineer can build any one of those boxes. The trouble is you are not building one box. You are building seven, and you own every seam between them. The back-buffer bug lived at the seam between the player and the browser. The one that gets almost everyone at least once lives at the seam between security and delivery: you sign the manifest so only your users can load it, and forget that each media segment carries its own request. The manifest opens, the segments come back 403, and the video plays perfectly for you and for no one else.

And now there is an eighth system

A year ago that list was the whole job. Now the same ticket asks the video to caption itself, clip its own highlights, and be searchable by what happens on screen. That is an eighth system, and it is the least stable one on the list. The models change every few quarters. Caption accuracy swings with audio quality and language. Running it yourself means a GPU budget and an evaluation harness to catch the week a model update quietly gets worse. It is the seven-systems problem again, on the one surface that will not hold still.

So what does that cost you to build?

Put rough, deliberately conservative numbers on it, for a competent team building its first video product. And most of these are not simply coding tasks. Before the encoding step is written, someone has to decide the ladder, the set of bitrates and resolutions a good adaptive stream needs, and learn the tooling to produce it, which for most teams means ffmpeg from the tutorials up. Before a byte is delivered, you choose and usually contract a content delivery network, which is weeks on its own before any code runs. One developer who tried told us the player alone took him three months, for web and Android, and even then it was not the whole feature set. He had built on standalone ExoPlayer and got caught out when Google folded it into AndroidX Media3, and he never got to the video analytics he actually wanted.

That last part is not a small feature. Building analytics the way FastPix does means collecting quality events off every player you support, web, iOS, Android, TV and the third-party players in between, stitching those events into sessions, and normalizing startup time, rebuffering and retention so a number means the same thing on each. That is why analytics is the row most teams start and never finish.

Deliberately conservative first-build estimates for a competent team building its first video product, with the rows overlapping in calendar time rather than summed; a solo developer runs them in series and much longer. Your numbers will vary. These are the ones we would defend.

The player and the analytics are the long poles; everything else overlaps around them. Conservatively that is six to twelve months to a first, incomplete build, against a few weeks on FastPix, so at least five times faster to launch, and often more. And the gap only widens afterward, because on your own stack that same list turns into maintenance that never ends.

Already running video? The build number is not yours; you have paid it. The row that is yours is the last one: maintenance, the steady drip of new devices, codecs and models, is what a working stack quietly costs you every quarter, and it is the line a switch flattens.

Where the weeks go

So those months are not spent typing. They are spent at the seams, and then they are spent on maintenance, which is the part that never ends. The day you launch is the day the real work starts. Apple ships a new player behavior. A newer codec becomes worth the bytes. A title goes viral and the transcode queue backs up at 2am. Each one arrives as unplanned work, and it arrives in the weeks you had set aside to build something else.

The move that changes the math

Here is the shift, and it is older than video. Good infrastructure changes the unit you think in. Before Stripe, taking a payment meant reasoning about bank files and acquirers; after, you reason about a charge. Before the cloud, standing up a server meant a rack and a purchase order; after, you reason about an instance. The systems did not disappear. Someone else runs them, and you get to work one level up.

Video has been waiting for the same move. The right unit is not a transcode job, a CDN behavior, or a license server. It is a single video asset, addressed by a playback ID, that you can upload to, play, secure, measure, and now ask questions of. When that is the unit you work in, the seven or eight systems fold into one thing you call and a handful of events you react to.

That is what FastPix is

You should not have to think about back buffers, per-segment tokens, or which codec a 2019 Android phone prefers. That is the idea behind FastPix. You create an asset, and the encoding ladder, packaging, storage, delivery and player come back done. The AI runs on that same asset. The data streams from the first play.

// The whole pipeline from earlier, as one call.
const fp = new Fastpix();
const asset = await fp.assets.create({
  inputs: [{ url }],
  playbackPolicy: "signed",
  inVideoAI: { captions: true, chapters: true, clips: true, search: true },
});

// Then react to an event, instead of polling a queue:
// POST /your-webhook  <-  { type: "video.asset.ready", assetId: asset.id }

You can try that shape in an afternoon. Sign up, send one video URL, get back a playback ID, and drop the player into your page; the first upload to a playing embed takes minutes, not a sprint. It is the quickest way to test any claim here against your own footage rather than take our word for it.

The back buffer is tuned for you. The segment tokens are checked at the edge, so the 403 seam does not exist. The player is free with FastPix and the same on web, iOS, Android and TV, with the caching, feed preload and offline that were three months of that developer's life built in. In-Video AI is a flag on the asset rather than a GPU cluster, so clipping a long video into ranked shorts, tagging scenes so they are searchable, and reframing to vertical are calls, not projects. And FastPix Video Data streams quality and engagement from the first play, so an engineer sees whether it works and the business sees whether anyone watched, from the same numbers, on every surface. It is the analytics layer that developer never reached. We have written up how to turn that raw data into an audience-retention graph of your own.

There is a people dimension too. Building video the usual way means finding the one engineer who knows HLS from DASH, and then your roadmap runs on their calendar; when they are out, video waits. Because that knowledge now lives in the platform, any developer on the team ships video, and the bus factor stops being one.

The same shape covers live. You ingest an RTMPS or SRT stream, the live ingest protocols, instead of a file, it plays through the same player and reports through the same data, and it records to an on-demand asset the moment it ends. So nothing above changes if your product is live as well as on demand.

The velocity comes from three things, and they are worth separating. There are fewer seams, because eight contracts became one. There are decisions you no longer own, like the encoding ladder and the ABR tuning, though a real platform lets you override them, so ask where you can. And there is data and events included, so you build reactive workflows and observability instead of standing up pipelines for them. The one that compounds is that the maintenance line goes flat: new devices, new codecs and new models are absorbed upstream. The team that would have spent the next year keeping video alive spends it on the product instead of the plumbing.

When you should still build it yourself

If video is your product, build it. If your edge is a novel codec, sub-second interactive latency at scale, or an air-gapped deployment a managed platform will not meet, then the pipeline is the thing worth your months, and you should own it. Know where any abstraction leaks before you commit, too: custom encoding ladders, specific DRM contracts, ultra-low-latency use cases, on-prem requirements.

Consolidating onto one platform also concentrates a risk worth naming out loud: when video is one dependency, its outage is your outage. So ask the questions you would ask of any critical vendor. FastPix delivers through more than one content delivery network, so no single one is a single point of failure, reaches most of the internet within tens of milliseconds from more than 300 locations, publishes its uptime on a public status page, and puts real engineers on support. That does not remove the dependency. It makes it one you can size and watch, the same way you already depend on your cloud provider and your payment processor.

If you are already running video

If you have a working stack, migration is a subtraction, not a rebuild. A migration tool bulk-imports the back catalogue by pulling from your existing storage rather than re-uploading it by hand, with step-by-step guides for moving off AWS and off Vimeo, among others. You can serve playback under your own custom domain, so new embeds stay on your hostname rather than a vendor's; the links that still point at your old provider do change, so you re-point or redirect them during the cutover. DRM titles need a one-time license step, and a large back catalogue is re-encoded on the way in, a transcode cost and a clock worth sizing up front. You can run both stacks in parallel and move traffic a share at a time, so there is a rollback if quality regresses, which is why this is usually days to weeks rather than a quarter. Your analytics history stays in the tool you already have, exported if you want it, while FastPix gives you clean quality and engagement data from the cutover forward. The honest cost is lock-in: your playback IDs and data model take the platform's shape, so ask how you get your assets and data back out before you commit, the same as with any dependency you did not write.

Teams who made the trade

"There were a lot of challenges using video. FastPix was refreshingly simple after attempting to build our own thing while trying with AWS. Our product's value, engagement, stickiness, and experience have all increased." Rajath Rao, Technical Director, Sclera (moved off AWS)

Knovo told a similar story, choosing FastPix over AWS and Kaltura to get the deep analytics and the web and mobile player in one place and cut the integration work. And Aadhan came off a different video API for the analytics, the AI and the playout it could not get in one place. By their own account, that let them move about 60% of their engineers off running video and onto building product and generating video. Velocity is not really about the first launch. It is about where your team spends the year after it.

On cost, and speed at runtime

FastPix meters per minute and discounts on volume the way everyone does, so the rate is competitive. The difference is what the bill does not do: no separate charge for the player, no double-metering on the AI, no surprise egress invoice, and no second contract for analytics. Add back the engineering months and the total is the honest comparison; here is how it lines up against AWS and Cloudinary. And buying the abstraction does not cost you speed at runtime: in FastPix's own reproducible benchmark, the same 21-minute source was playback-ready in 83 seconds against 142 for the next provider, and the harness is public, so you can run it on your own files.

Getting more strategic

With that work handled, the win is not really the months you save. It is where your best people spend them. Encoding ladders and back buffers and segment tokens are the price of entry, not the reason anyone picks your product over the next one. The teams that move fastest treat that as the whole game: keep the work every video app needs off your roadmap, so the work only your team can do gets your strongest engineers. While a competitor is still assembling video, you are shipping the thing your users will actually compare you on.

There is a sharper version of this now, because video itself is changing. It used to be something users watched; increasingly it is something your product and your AI act on, a video your app can search, clip, caption and reframe, not only play. We have written about that shift here. The strategic part is that on FastPix these are not a separate project bolted onto your stack: In-Video AI and AI clipping run on the same asset you already uploaded, in the same call that encoded it. So the team that offloaded the plumbing does not just move faster on the old features; it can ship the AI-native ones a competitor still treats as a quarter-long project.

More focus on the finer details

There is a second-order effect that is easy to miss. When a team is not spending its attention on token expiry and back buffers, it spends that attention on the parts of the product users actually feel: the shape of the player, the way a feed loads, the moment a clip is offered, the small things that make an app feel considered rather than assembled. FastPix removes the plumbing, not the craft. It will not make a dull show worth watching or a weak course worth finishing, and a clumsy player is still yours to fix. But the craft is where products are won, and it is exactly where a team's attention goes once the infrastructure is off its plate.

Where the business value shows up

For a founder, the value of all this is measured on the calendar. A creator platform that would take two to four quarters to build its own video stack can be in market in a few weeks on FastPix, with the table stakes the incumbents have on day one: upload, adaptive playback, a branded player, clipping, search and analytics. In a category where the first credible product tends to win the creators, that head start compounds. And it continues past launch: instead of a team that spends the next year maintaining the pipeline, you have one that has moved from infrastructure management to the product itself. That is what Aadhan's number really says: more of its engineers building the product, fewer keeping video alive.

The ticket still says add video. The difference is whether it costs you two weeks or two quarters, and whether your best engineers spend the next year on your product or on a pipeline.

If you want to see it on your own content, start free with $25 in credits, or read the docs.