FAST Channel Operations
For a European media company I built the operations center of its FAST channel, on air across 12 markets: catalog, scheduling, asset delivery to the distributor and multi-source analytics in one platform, with automated daily ingestion and playout publishing from the product itself.
- My contribution
- I designed and built the channel operations platform, with automated ingestion and playout publishing.
- Who it serves
- Programming and operations teams at a European media company.
- Scope
- Channel on air across 12 markets. Three daily pipelines connect catalog, scheduling and analytics.
Interactive replica
A navigable replica of the platform's modes with fictional data: same layout, same logic, no real data.
Platform pillars (replica)
By Channel · channel aggregates · consumption by hour of day
The programming question is at what hour the channel gets watched. Each bar is an hour; the line is the channel average. Anything above it is a slot that performs; anything below is filler time.
- HOV (h)
- 1,994
- Sessions
- 1,568
- Ad imp.
- 4,210
- Airings
- 255
The peak sits in primetime and the average leaves out almost the whole overnight. The same title performs differently at 3am and at 9pm.
Hour × day map
The same signal crossed by weekday shows where and when consumption happens.
More case contextCase overview, data architecture and product decisions.
Case overview
The operations center of a live linear TV channel: one product covers the full cycle (catalog, grid planning, asset delivery to the distributor and multi-source analytics), with automated daily ingestion and playout publishing from the platform itself.
- Modes
- Assets DB, Scheduler, MAM and Analytics (+Admin)
- Sources
- FAST distributor, YouTube/BigQuery, FAST TV platform measurement and CRM
- Ingestion
- 3 daily n8n pipelines over authorized read-only access
- Status
- Channel on air since Jul 2026 across 12 markets
Data architecture
Three daily n8n pipelines ingest the sources over authorized read-only access. Supabase is the canonical database: versioned SQL scoring lives there. The platform reads server-side and publishes to the playout via the Executor.
Case decisions
Model
The platform follows the channel's factory flow: the catalog feeds the Scheduler, the MAM delivers assets to the distributor and Analytics closes the loop by measuring real performance. All of it runs on a shared layer of roles, security and versioned configuration.
On-air execution
The Executor takes the saved plan and publishes it to the distributor's playout in an assisted, supervised way, as one continuous chain with no gaps or overlaps. It adds a prior simulation and read-only verification of what actually aired.
From the spreadsheet to the platform
The scheduler started as a Google Sheets workflow, with a live content base in a spreadsheet and an Apps Script (auto_grid) that built the grid. When the platform centralized the channel it absorbed that workflow as one more mode, and today the saved plan is the grid's source of truth.
Privacy
The public case shows architecture, logic and product decisions with anonymized data: no company or vendor names, no real titles, credentials or financial metrics. Scale figures are real.
Facets
Tools
- Next.js + TypeScript
- the web platform: mode rail, server-side RBAC and every view's rendering
- Supabase (Postgres)
- canonical database: catalog, grid, versioned SQL scoring, matviews and audited RLS
- n8n
- 3 daily pipelines ingesting distributor reports, YouTube/BigQuery and FAST TV platform measurement over authorized access
- BigQuery
- the channel's YouTube universe and perpetuity metrics feeding the tiers
- Executor
- assisted, supervised publishing of the grid to the distributor's playout, with prior simulation
- Python
- imports/exports CLI, syncs (CRM, BigQuery) and the database loading engine
- Railway
- production deploy with auto-deploy from main
- Google Sheets + Apps Script
- the Scheduler's genesis with a live spreadsheet base and automatic grid (auto_grid) before being absorbed as a mode