Architecture and sizing
A high-level design against your traffic, your territories and your constraints — with the trade-offs written down rather than implied.
We build it. Your team runs it.
The whole platform deployed into your estate — your hardware, your AWS account, your repository — and then handed over to a team that has been trained on it, with runbooks written against the environment they actually have.
Who an implementation is for
Three organisation types account for almost every implementation engagement. If none of these describes you, the consulting engagement is the cheaper first step.
- OTT platforms
- Services already streaming that want the estate rebuilt as code in their own accounts, with the team trained to run it.
- Telcos and ISPs
- Operators with an existing NOC and a network to deliver over, who want the platform inside it rather than rented from outside.
- Enterprise network operators
- Organisations that already run infrastructure and intend to own this too, with a team ready to take the pager at handover.
Handover is the deliverable, not the last slide
Most infrastructure projects hand over a system that only the people who built it can operate, and everybody involved discovers this about four months later. The way to avoid that is not more documentation — it is that the environment was reproducible from a repository from day one, and the people who will run it watched it being reproduced.
So the estate is Terraform before it is hardware. It gets destroyed and rebuilt during delivery, deliberately, until that is boring. By the time it carries traffic, your team has seen the whole thing come up from nothing more than once.
What's included
The estate, as code
Every resource in Terraform, in your repository, applied by a pipeline. No console step anywhere in the delivery path.
The platform, running
Services deployed and integrated, catalogue ingested, encoding tuned to your material, apps branded and submitted.
Load tested at your peak
Tested at the concurrency you actually expect, not the concurrency that is convenient to test, with results you can show a board.
Runbooks and training
Operational documentation written against your estate, and sessions with the people who will be carrying the pager.
A support line that stays open
A defined support window after handover, and an optional retainer if you want one permanently. Neither is a condition of the other.
How an implementation runs
Discovery & HLD
What you have, what it costs, what it has to do. Out comes an architecture, a sizing and a scope with the trade-offs stated.
Estate build
Terraform first. The environment comes up from an empty account or an empty rack, repeatedly, until that is unremarkable.
Platform delivery
Services, catalogue, encoding, apps and observability — integrated and load tested at your expected peak.
Handover
Runbooks, training and a support window. Your team runs the next deploy while we are still in the room.
Is this the right engagement?
You have an operations team
You already run infrastructure and want to own this too. You want the design and the build done properly, and then you want the keys.
Nobody will own it afterwards
If there is no team to hand over to, a handover is a fiction. The managed engagement exists for exactly this case and is the honest answer.
Do we need to hire streaming engineers?
For the deployment, no. It is stood up by us, and the estate arrives declared in Terraform rather than assembled by hand — which means the knowledge of how it was built is in the repository rather than in whoever built it.
For running it afterwards, the honest answer is that you need operational capability rather than streaming specialists. Somebody who can read a dashboard, follow a runbook and escalate is enough for the ordinary week, and that is usually a person you already have. What an owned platform genuinely adds to an operations team is hardware: a disk fails, a node needs replacing, and somebody has to be reachable when it happens.
Where a streaming engineer earns their salary is in the decisions rather than the operations — how the ladder is tuned for your audience, when the edge needs another node, what a rise in rebuffering on one ISP actually means. Those are the calls we make during an engagement and hand over deliberately, and most operators keep us for exactly that rather than hiring for it in year one.
The alternative shape, and it is a legitimate one: retain the engineering with us and keep no specialist in-house at all. That is what the managed engagement is for. What we will not tell you is that an owned platform runs itself, because nothing that holds your audience's video runs itself.
The things people ask first
Who owns the code and the infrastructure?
You do. It is your repository, your cloud account, your hardware. The Terraform, the runbooks and the configuration are yours at the end of the engagement and during it.
How is this priced?
Fixed scope, fixed fee, agreed after discovery — because a price quoted before anyone has looked at your estate is a guess dressed as a number. Discovery itself is a small, separately scoped piece.
What if we want you to keep running it?
Then the managed engagement continues from the same delivery. Nothing about the build changes; only who holds the pager afterwards.
Scope an implementation
Send what you have — hardware, cloud account, existing platform, launch date — and the first thing back is an architecture and a scope, not a proposal template.