The context
A vendor supplies television and video-on-demand solutions to telecom operators in several countries. Each operator wants its own application, in its own brand, with its own catalogue and local specifics — but none wants to pay for a full application built from scratch.
The challenge
It is a classic problem, and rarely solved well: how do you serve N customers from one codebase without each new customer breaking the previous ones?
The two usual failures are well known. Either you fork the project per operator, and after four variants nobody knows which fix landed where. Or you pile conditionals into a common trunk, and the code becomes unreadable.
On top of that came a field constraint: these applications run on networks and devices unlike those of Western Europe. Variable bandwidth, an older device fleet, and data-cost constraints on the user side.
What we did
- A shared library holding everything that does not change between operators: stream playback, catalogue navigation, session handling, common UI components.
- Per-operator applications built on that library, carrying only what is genuinely their own — visual identity, catalogue, local specifics.
- Self-hosted audience measurement, rather than a third-party service. On this kind of product, knowing what gets watched is strategic for the operator: the data stays with them.
- Connected-TV versions, with the constraints particular to that medium: remote-control navigation, legibility at three metres, no comfortable keyboard input.
The outcome
Several operator applications delivered from a common foundation, maintained in parallel over three years.
The lesson from this kind of project is easy to state and hard to hold to: the boundary between the foundation and the variant has to be drawn early, then defended. Every time one operator’s specific need creeps into the shared trunk “just this once”, it is the foundation that pays for it in later years.
Screenshots
Client covered by a confidentiality agreement