Every engineering team that has looked at a streaming stack has concluded it is three months of work. It is not, and the reason is worth understanding whichever way you decide — because the parts that take the time are not the parts that look hard.
Ask a good engineer to scope a streaming platform and they will scope the interesting half: an encoder pipeline, a packager, a player, a catalogue API. That half is genuinely a few months, and it is genuinely not the work.
The work is the agreement between fifteen components about four things — who this viewer is, what they are entitled to, which key decrypts this title, and what just happened on their screen. Every one of those crosses every service. Getting them consistent is most of the effort and none of the demo, which is why a build that looks 80% done at month three is usually 40% done.
The second thing the estimate misses is that a streaming platform is not finished when it works. It is finished when it survives a bad night: an origin that stops answering, a live feed that drops mid-match, a store review that arrives late, a payment gateway that sends the same notification twice. Each of those is a day of work to handle and a quarter of an outage to discover.
None of them is the encoder.
Whether this viewer may watch this title right now is asked by the player, the API, the edge and the key service, and they have to agree at the moment of asking rather than eventually. Subscriptions, one-off purchases and trials each answer it differently.
Encrypting content is easy. Releasing the key to exactly the right session, expiring it, re-checking it on every segment, and doing that without adding a round trip to the first frame is the part that takes months.
One phone application is a project. The same experience on a television is a different navigation model, and each store is its own review queue, its own account and its own release cadence.
Collecting playback events is a week. Knowing that rebuffering rose on one ISP in one city, and being able to tell that from a bad encode, is an ingestion and rollup problem that grows with your audience.
Backups that have been restored, secrets that are not in a repository, a change process that survives the person who wrote it. This is the half that never appears in a build estimate and always appears in an incident.
Codecs move, stores change their requirements, a gateway deprecates an API. A platform is a maintenance commitment, and the team that built it is the team that carries it.
When the product is the platform. If your differentiation is something no platform does — an unusual rights model, a live format nobody supports, an interaction that is the reason people come — then building is not a cost, it is the product, and buying would hand your differentiator to a roadmap you do not control.
When you already carry the capability. An organisation with a platform team, an on-call rotation and infrastructure they already run is paying most of the cost of building whether or not they build. For them the marginal cost is the streaming-specific knowledge rather than the whole estate.
When the timeline genuinely allows it. Building is the right answer far more often at eighteen months than at four, and the honest question is not whether your team could build it but whether they could build it and also do the other thing they were hired for.
When the launch date is fixed and external. A build slips against a season, a tournament or a marketing commitment, and the version that ships against a hard date is the version that will be rewritten.
When the team is one or two people. A streaming platform is not a large amount of code, but it is a wide amount of code, and a wide surface with a narrow team is how a system becomes unmaintainable while everybody is still proud of it.
What usually happens instead, and it is the most common outcome of these conversations: a hybrid of the two. The client keeps whatever they have already built that works — often the CMS, often the identity system — and takes the pipeline, the delivery and the apps. That is a normal engagement, and it is a better answer than replacing something that is doing its job.
The third path is worth naming too. Licence the platform and run it yourself: you get the integration and the Terraform, and your team operates it. It is the cheapest route to the same outcome for a team that already runs infrastructure well.
Then the useful conversation is which parts to keep. Several of these engagements have ended with a client keeping their CMS and taking the pipeline, which is a better outcome than replacing something that works.