All case studies

Media & TV · Client work · 2026

Artwork for 100+ TV channels, sourced automatically.

Selecting artwork for one schedule entry dropped from about ten minutes of manual search to under a minute. The workflow covers 100+ channels and fills in up to ten images per title on its own.

  • 10 min → <1 min

    per schedule entry

    Time to select artwork, before and after.

  • 100+

    TV channels

    All covered by the same workflow.

  • 10

    images per title

    Sourced and written back into the sheet automatically.

Client
Polsat Media
Stack
  • n8n
  • TMDB API
  • Google Sheets
  • Google Custom Search

Context

Polsat Media sells advertising across more than a hundred TV channels. Every film and every programme in the schedule needs a poster and a few images from the film itself before it can be packaged for advertisers. In early 2026 that artwork was found by hand: someone opened a browser, searched, judged and downloaded, for several titles a day on each channel.

Problem

Roughly ten minutes of image search per schedule entry. The quality drifted depending on who was clicking. High-resolution files were the hardest part to get right, and the same title kept getting sourced twice by two people. An advertising team was spending a large part of its day on image search instead of advertising.

What I built

An n8n workflow with five moving parts:

  1. Read the schedule sheet. Channel, title, production year, one row per entry.

  2. Detect the entry type. Films and TV programmes need different sources, so the workflow decides which path a row takes before it searches anything.

  3. Films go to a film database. Official posters and frames from the film, with the production year narrowing the candidates.

  4. Programmes go to image search. No canonical database exists for most of them, so the workflow queries and then filters hard.

  5. Score every candidate before accepting it. Four rules decide what is good enough to use. This is where the value sits.

The four scoring rules

  • Polish-language versions rank above international ones.
  • Frames with subtitles burned into the picture get pushed down.
  • Anything below the resolution threshold is rejected outright.
  • Duplicates of an image already accepted are removed.

Up to ten images per title are written straight back into the sheet. Rows that are already filled get skipped, so the workflow can run again without making a mess of earlier work.

Schedule rowchannel · title · yearFilm orprogramme?FILMPROGRAMMEFilm databaseofficial artworkImage searchfiltered hardScoringlanguage · subtitlesresolution · duplicatesup to 10 accepted images written back into the row
One row in, two possible sources, one scorer deciding what gets written back.

Result

Artwork selection for one schedule entry went from about ten minutes to under a minute. The workflow covers 100+ channels and fills in up to ten images per title on its own. The advertising team got its day back.

The hard part

Nobody demos this part. Broadcast title strings are not identifiers. The same name belongs to three different productions, remakes collide with originals, and the production year narrows the field without settling it. Matching the right image to the right title was hit and miss for weeks: every fix for one class of mismatch broke another one I only found later. The API calls were the easy half.

What I would build differently today

In March 2026 a workflow was the honest answer. Building a real application meant weeks I did not have, so the matching logic lived inside n8n nodes, the spreadsheet was the database, and low-confidence matches had no review step.

Today I would build the same thing as an application: matching logic in tested code, a fixture set of the titles that broke it, a review screen for the matches the scorer is unsure about, a database instead of a sheet. With Claude Code that is no longer weeks. The line between "automate it in n8n" and "just build the software" has moved, and most of my old workflow cases now sit on the other side of it.

A workflow is a deliverable. A system somebody else can own is the actual outcome. That distinction is now the first thing I design for.

See also.