The applications people watch on
Web, Android and Android TV are shipping today; iOS and Samsung Tizen are in development. Branded as yours, published under your accounts, talking to your APIs.
What you are actually buying
A complete streaming platform, deployed into infrastructure you own, with the viewer applications, the admin tools and the delivery pipeline that make it a service rather than a stack. It is a build and a handover, not a subscription — at the end of it the platform is yours, running, and documented as code.
One platform, delivered to you — not rented back to you
Most streaming offers fall into one of two shapes. Either you rent a hosted platform and pay per subscriber, per gigabyte and per transcoding minute for as long as you operate — or you hire integrators to assemble open-source parts and inherit whatever they leave behind. The first is comfortable and gets expensive exactly as you succeed. The second is cheap to start and expensive to run, because nobody owns the whole.
This is a third shape. The platform already exists, it already carries a live consumer service, and it is deployed into your estate and handed to you. You get the running system, the applications your viewers use, the tools your staff use, and the Terraform that produced all of it. No per-viewer meter, no per-gigabyte egress line, and no part of it that only the vendor can change.
So the question this site is really answering is not which features you want. It is where the platform should run, what state you are starting from, and who operates it afterwards. Those three answers are the whole decision, and each of them has a page.
Who this is for
Organisations that intend to operate a streaming service themselves, rather than to rent one indefinitely.
- Broadcasters
- Terrestrial, satellite and cable operators taking linear channels and a back catalogue to streaming without renting the delivery back.
- OTT platforms
- Existing services whose cost per viewer is moving the wrong way, or whose hosted platform has become the constraint on what they can build.
- Telecommunications operators
- Networks that already carry the traffic and would rather terminate video inside their own estate than pay to fetch it from outside.
- Enterprises and institutions
- Organisations with video, an audience and a data-residency or budget constraint that a public streaming service cannot satisfy.
What arrives in a deployment
The same eight pieces every time. What changes between deployments is where they run, not what they are.
Three ways to deploy it — chosen by constraint, not by tier
These are not good, better and best. They are three answers to where your money and your data are allowed to sit, and the platform is identical in all three.
| The question | Full on-premises | Hybrid | AWS |
|---|---|---|---|
| Choose it when | Cost and data control decide it | You need cloud elasticity for sign-in and billing, but not for video | Your organisation has already standardised on AWS |
| Applications run | Your hardware | AWS | AWS |
| Encoding runs | Your GPUs | Your GPUs | AWS |
| Video is served from | Your edge | Your edge | AWS and CloudFront |
| Data residency | Entirely in your walls | Media local, control plane in cloud | AWS regions |
| Cost shape | Capital, then flat | Mixed — the expensive half is owned | Operational, scales with traffic |
| Scales by | Adding hardware you plan for | Cloud absorbs spikes, edge absorbs volume | The cloud, automatically |
Which of these is your actual situation?
The deployment model is the second question. This is the first one, and it is the page worth reading next.
How the work actually runs
Four stages. The first one is the one that decides whether the rest should happen at all.
Discovery
Your content, your audience, your existing hardware and your constraints, against what this platform needs. It ends in an architecture and an honest date — including, sometimes, the answer that this pattern does not fit you.
Design and declaration
The estate is written as Terraform before anything is provisioned. You can read the whole deployment as a diff, and so can we, which is why the build stage rarely produces surprises.
Build and cutover
Provisioning, encoding of the back catalogue, the applications submitted to the stores, and a migration path if you are coming off something else. Cutover is planned as an event with a rollback, not as a switch.
Operate
Your team runs it, we run it, or your team runs it with ours on call. Whichever it is, the repository and the documentation are yours from day one — the option to change your mind later is part of what you bought.
Why there is no price list on this site
A deployment is priced against what it has to carry, and the inputs are specific enough that any published figure would be wrong for almost everyone reading it. Catalogue size decides how much encoding is in front of you. Concurrent viewers decide how much edge capacity you need. Whether hardware already exists changes the capital half completely. Rights agreements decide whether AES-128 is sufficient or a studio DRM is required, and that is a real cost difference — AES-128 ships today, a licence server is built in the engagement.
What can be shown honestly is the shape of the saving and the arithmetic behind it, which is what the economics page does — the cost of serving a terabyte from owned capacity against renting the same terabyte, using the numbers from a service that is actually running. Take those figures and put your own traffic through them before you talk to anyone, including us.
The quote itself comes out of discovery, because that is the first point at which it would be a real number rather than a comfortable one.
What buyers ask before anything else
Do we own it, or are we licensing it?
You own the deployment. The infrastructure is yours, the data is in your database, and the Terraform that built it is in your repository. There is no meter and no switch anybody else can throw.
Do we need an engineering team to run this?
Not on day one. Plenty of customers take the managed option and keep their own team on content and product. The point of the code handover is that the choice stays open — you are never unable to leave because only we know how it was built.
How long does it take?
It depends on catalogue size, rights constraints and how much hardware already exists, and discovery is what turns that into a date. What is fixed is the order: nothing is provisioned before the architecture is agreed.
Can we start small?
Yes, and it is often the right call — one deployment model, a subset of the catalogue, one or two applications. The estate is declared as code, so growing it later is a change to the declaration rather than a rebuild.
What about the content rights we already have?
They usually decide the encryption, not the architecture. Independent and regional content is normally served well by AES-128 with per-segment authorisation, which is what this platform runs today. Studio agreements typically require Widevine, PlayReady or FairPlay, and that needs a licence server this platform does not run yet — building one is scoped into the engagement, and it changes the key path and nothing else.
Is this a product or a project?
Both, in the order that matters: the platform is an existing product carrying a live service, and the engagement that puts it into your estate is a project with a start, a cutover and an end.
Not sure which of these is you?
Describe what you have and what you are trying to launch. The first thing back is an honest read on whether this fits, not a proposal.