High-level design
The architecture drawn tier by tier, with the trade-offs written down rather than implied and every failure mode enumerated.
Discovery, delivery, handover
The same three phases whichever engagement model you pick. What changes at the end is who holds the pager — not how the work is done, and not what you are left holding.
Who discovery is for
Discovery is scoped and priced on its own, so it is the right first step whether or not anything follows it.
- OTT platforms
- Services with a bill that has stopped making sense, or an architecture decision nobody internal can settle.
- Telcos and ISPs
- Operators deciding between building, buying and peering, who want the arithmetic done before the vendor conversation.
- Enterprise network operators
- Teams holding a proposal and a launch date, wanting both checked against the estate they actually have.
Nothing is priced before it is understood
A fixed price quoted before anyone has looked at your estate is a guess wearing a number, and it gets recovered later through change requests. So every engagement starts with a small, separately scoped discovery, and the fixed price for the work itself is agreed after it.
Discovery produces something you can use on its own: an architecture, a sizing, and a cost model you can take to a board. If you decide to stop there, or to hand it to someone else to build, that is a legitimate outcome and the deliverable is yours.
What discovery delivers
Five documents, all of them yours whatever you decide afterwards. Each one is usable on its own — by us, by another vendor, or by your own team.
Capacity sizing
Hardware and cloud sized against your measured peak concurrency and bitrate ladder, not against an average that never occurs.
Cost model
Your twelve months of invoices matched against measured traffic, then the same traffic priced on owned capacity including amortisation, power and transit.
Migration plan
The order of operations if you move, with the reversible steps separated from the ones that need a rehearsed rollback.
Scope and fixed price
What the build would cost, fixed, because by this point somebody has actually looked at the estate. Valid whether we do the work or somebody else does.
The recommendation
Including, where the arithmetic says so, that you should change nothing. An advisor who only earns from the build has an incentive not to say that.
Phase one — discovery & high-level design
Two to three weeks. Ends with a document, a number and a recommendation — including the recommendation to change nothing.
What you have
Current platform, hardware, cloud accounts, contracts and who operates them today. Read rather than asked about, where there is something to read.
What it costs
Twelve months of invoices matched against measured traffic, so cost per delivered gigabyte and cost per viewer become visible numbers.
What it has to do
Peak concurrency, territories, rights constraints, launch date and the service level the business genuinely needs — which is usually not the one first asked for.
The architecture
A high-level design with the trade-offs written down and the failure modes enumerated, plus a sizing you can defend.
Phase two — delivery
Terraform first. The environment is reproducible from a repository before anything depends on it.
Estate as code
Every resource declared and applied by pipeline. The estate is destroyed and rebuilt during delivery, deliberately, until that is unremarkable.
Platform deployed
Services integrated, catalogue ingested, encoding ladder tuned to your material, apps branded and submitted to the stores.
Instrumented before launch
Metrics, logs, traces and per-session playback telemetry running before the first viewer arrives, not bolted on after the first incident.
Load tested at your peak
At the concurrency you actually expect, not the one that is convenient to test — with results written down.
What delivery looks like day to day
The same workflow on your AWS account and on your metal. Your team can watch it, and by the end they are running it.
# Every change, every estate, every phase of the engagement.
git switch -c add-vod-edge-node
$EDITOR infra/edge/nodes.tf
terraform fmt -check && terraform validate
terraform plan -out=tfplan # attached to the merge request
# review -> approve -> merge -> pipeline applies
# By handover, your team has done this themselves. More than once.Phase three — handover & support
The deliverable is a team that can run it, not a document that says they could.
Runbooks
Written against your estate, service by service, including every failure mode the architecture was designed for.
Training
Sessions with the people who will carry the pager, recorded, and a real deploy performed by them while we are still in the room.
Support window
A defined period after handover where questions get answered quickly, so the first unfamiliar week is not faced alone.
Then your call
Continue with a retainer, move to a managed agreement, or carry on alone. None of the three is a condition of the others.
The things people ask about the process
How long does the whole thing take?
Discovery is two to three weeks. Delivery depends on catalogue size, how much hardware already exists and what has to be migrated — and discovery produces an honest date rather than an encouraging one.
Can we stop after discovery?
Yes, and some do. The architecture, the sizing and the cost model are yours, and they are useful whoever builds from them.
What do you need from our team?
Access to the evidence during discovery, and the people who will operate it present during delivery. The second one matters more — a handover to people who were not there is a document, not a handover.
What if the scope changes mid-delivery?
It gets re-scoped and re-priced in writing before the work happens. Discovering a change request in an invoice is how trust ends.
Start with discovery
It is small, separately scoped, and it produces something useful whether or not anything follows — an architecture, a sizing and an honest cost model.