What we build
Television applications for broadcasters
Across every runtime in the living room, from one code base and one backlog.
We qualify hard, deliberately: if you want a single app on a single platform, almost any web agency can help you and we are the wrong call. What we are good at is the case where one editorial team has to serve four different televisions and cannot afford four of everything.
Platforms
| Platform | Runtime | Packaging | Distribution |
|---|---|---|---|
| HbbTV | browser runtime | URL + Content-Type | no store |
| Samsung Tizen | Chromium runtime | .wgt | Seller Office |
| LG webOS | Chromium runtime | .ipk | Content Store |
| Android TV | WebView / native | .apk | Play Store |
They are not variants of one thing. The differences between them are the work. How one codebase serves all four →
Six kinds
Six kinds of application
- Media libraries
- Catalogue, search, continue-watching, and a player that still behaves on a ten-year-old set. Written out: Bibel TV · ProSiebenSat.1.
- EPG
- Programme data, now and next, themed channels — fed from the broadcaster's own systems rather than maintained twice. Written out: ProSiebenSat.1.
- Livestreaming
- Several simultaneous streams, with a channel change that feels like television rather than like a web player reloading. Written out: Bibel TV, four livestreams.
- Operator apps
- Privileged HbbTV applications that run on the platform itself rather than on a channel — a different technical contract and a different counterpart. We co-built the one on HD+ — what that involves.
- Animated Switch-In
- The HbbTV advertising format that invites a viewer out of the commercial and into the application without losing the commercial. It is the format that makes an HbbTV app pay for itself — how it is built.
- Format landing pages
- Campaign screens for a running show — The Voice of Germany, Germany's Next Topmodel — built to a broadcast schedule rather than a project plan. Why that changes the architecture.
Behind them
The platform behind them
Most of what an editorial team experiences is not the app; it is what feeds it. We build headless Drupal with React frontends, REST and GraphQL, Elasticsearch where search has to be real, automated daily ingest from pre-production systems, and playlist tools the schedulers actually use.
How we work
About eight people in Feldkirchen near Munich. You talk to the managing director, not to an account layer.
One backlog across all platforms. That is where the shared codebase stops being an architecture diagram and becomes something you feel: one release train, one QA pass, one feature request instead of four.
Edges
What we do not do
No conformance certification — we are not a test house. No device certification lab. No broadcast playout. And no single-platform consumer apps, for the reason in the first paragraph.
Clients
Tell us what you are building.
Christian answers these himself, usually within a working day.