📺 Episode
One watchlist for TV, regardless of where it streams.
Episode is an early-stage personal streaming companion I’m building to solve a problem I keep running into: I don’t really care which streaming service a show belongs to. I just want to know what I’m watching, where I left off, and when the next episode comes out.
The idea is intentionally simple:
Track shows, not streaming services.
🚧 Status: Early-stage / currently building. The product architecture and data model are defined, but most application functionality has not been implemented yet.
The Problem
Watching television has become fragmented across streaming services.
Each service knows what you’ve watched on that service, but the user’s actual TV life doesn’t work that way.
A show might be on one platform today and another tomorrow. Two shows you’re following might live on completely different services. And keeping track of when weekly shows return often means checking several different apps or searching manually.
The product question I’m exploring is:
What would a TV tracker look like if the show—not the streaming service—were the center of the experience?
The Product Idea
Episode is designed around three core jobs:
One watchlist
A single place for everything I’m watching, regardless of streaming provider.
Episode-level progress
Track exactly which episodes have been watched rather than treating an entire show as watched or unwatched.
What’s next?
A forward-looking feed showing upcoming episodes and air dates for shows on the watchlist.
The goal isn’t to become another streaming platform.
It’s to provide the lightweight organizational layer that sits above all of them.
Product Decisions
No account unless there’s a reason for one
This is currently a single-user product, and watch state lives locally in the browser.
That’s intentional.
Authentication, user accounts, cloud storage, password recovery, and account management would add significant product and technical complexity without making the core idea more useful to me right now.
If syncing across devices becomes important later, that’s a reason to revisit the decision.
For now, it isn’t.
Use different data sources for different jobs
No single source gives me everything the product needs.
The current architecture uses:
- TMDB for show metadata, artwork, and streaming-provider information
- TVmaze for episode schedules and air dates
- IMDb IDs as a shared identifier for connecting records between the two
Internally, a show keeps the relevant IDs from each system so the product can combine information without accidentally treating the same show as multiple shows.
Keep the architecture proportional to the product
Episode is designed to run as a static client application on GitHub Pages rather than starting with a backend service.
The client can communicate directly with the required data sources and cache information locally.
That’s enough architecture to test the core product idea without building infrastructure the product doesn’t need yet.
What I’m Building Toward
The initial experience is intentionally narrow:
- Search for a TV show
- Add it to a personal watchlist
- See which service currently carries it
- Track watched and unwatched episodes
- See upcoming episodes and air dates
- Maintain one view across streaming providers
From there, I’ll use the product myself and decide what actually deserves to exist next.
Why This Repo Is Different
Most of my projects in this GitHub profile show products after I’ve already made a lot of the important decisions.
This one is earlier.
I’m keeping Episode public while I build it because I think the decisions made before a product has a lot of features are interesting too: what not to build, which assumptions to test first, where complexity is justified, and where it isn’t.
The goal isn’t to demonstrate how many features I can ship.
It’s to build the smallest useful version of something I actually want.
Current Architecture
Need Approach Show metadata & artwork TMDB Streaming providers TMDB Episode schedules TVmaze Cross-source matching IMDb ID Watch state Browser-local storage Hosting GitHub Pages Frontend Vite / TypeScript
Status
🚧 Actively building — early stage.
The repository currently contains the application container and architecture. Core product functionality is still being implemented.
⸻
About me
I’m Ryan Samuelson, a product leader and hands-on builder based in Portland, Oregon.
I’ve spent 10+ years working across product, growth, analytics, and data at companies including Nike, Prime Video, Galvanize, and Redfin. Today I build products independently using customer insight, data, experimentation, and AI-assisted development.
I like finding messy problems, figuring out what matters, and building enough of the solution to learn something.