Short answer: put business rules, content and entitlements in one backend; expose them through a versioned API designed around client use cases; support device-appropriate authentication (including activation codes for TVs); cache aggressively at the edge; and keep old app versions working. Decide these in the POC — they're the expensive things to change later.
1. One source of truth for rules and content
The most costly multi-platform bug is inconsistency: a show available on web but not on TV, a subscription honoured on iOS but not Android, a price that differs by app. These happen when rules live in clients. Keep them in the backend:
- Content and metadata — one content model, with device-specific assets (artwork sizes, formats) attached to it.
- Entitlements — who can access what, decided server-side for every request that matters.
- Configuration — feature flags, menus and rails served by the API so you can change them without app releases.
2. Design the API around screens, not tables
A generic CRUD API forces each client to make many calls and stitch results together. That's tolerable on a laptop and painful on a mid-range TV. Two patterns help:
- Use-case endpoints — e.g. a "home screen" endpoint returning rails with just the fields a tile needs.
- Backend-for-frontend (BFF) — a thin layer per client family (web, mobile, TV) that adapts shared services into what that client needs. Useful when clients diverge significantly.
GraphQL can serve a similar purpose by letting clients request exactly what they need; REST with well-designed resources and sparse fieldsets works too. Choose based on your team and caching needs — CDN caching is generally simpler with REST.
3. Authentication for devices without keyboards
Typing an email and password with a TV remote is miserable. The common pattern is a device authorisation flow: the TV shows a short code or QR code, the user approves it on a phone or computer where they're already signed in, and the TV receives its tokens. Standards such as the OAuth 2.0 Device Authorization Grant describe this flow.
Plan for device management too: listing active devices, limiting concurrent streams and remotely signing out a lost device.
4. Cache at every layer
Most multi-platform traffic is read-heavy and highly cacheable — catalogues, menus, configuration. Separate public, cacheable responses from personalised ones (continue watching, entitlements) so the former can be served from a CDN. Set explicit cache lifetimes and have a plan for invalidation when editors publish.
5. Old app versions never fully disappear
Web clients update instantly. Mobile and TV apps don't — users update late, some devices stop receiving updates, and store reviews add delay. Your API must support several client versions at once:
- Prefer additive changes; avoid renaming or removing fields clients depend on.
- Version deliberately when breaking changes are unavoidable.
- Send the client platform and version with each request, and keep a minimum-supported-version mechanism to prompt upgrades.
6. Observe by platform
Logs and metrics should be broken down by client platform and version. "Errors are up 3%" is hard to act on; "errors on one TV platform's latest version are up" points to the fix.
What to decide in the POC — and what can wait
| Decide in the POC | Can usually wait |
|---|---|
| Core data model for in-scope features | Microservice boundaries |
| Authentication approach for every client type | Multi-region deployment |
| Where entitlements and business rules live | Advanced personalisation |
| API style and versioning policy | Fine-grained performance tuning |
| Caching strategy for public content | Full analytics pipeline |
Getting the left column right is what lets a POC grow into the production product instead of being rewritten. How we approach POC development.