Designed & built Live

WatchTheOutdoors

A curated discovery layer over outdoor video: YouTube metadata aggregated into a searchable catalog with a cache-first data strategy, admin channel tooling, and quota-aware scheduled refresh.

Project
WatchTheOutdoors.com
Role
Founder & Developer
Timeline
2026
watchtheoutdoors.com
WatchTheOutdoors homepage: 'Where the wild comes into focus' with entry points for browsing videos and terrain, above a grid of curated outdoor video thumbnails

The idea

Outdoor video on YouTube is abundant and badly organized. Recommendations chase watch time rather than intent, so finding good content about a specific activity means fighting an algorithm optimized for something else.

WatchTheOutdoors is a curation and discovery layer: aggregate metadata from channels worth watching, organize it by category and channel, and make it browsable and searchable on its own terms.

The interesting engineering problem

The YouTube Data API has a hard daily quota. Any product built on it that queries the API per page view will exhaust its quota and break — so the architecture is really about not calling the API.

The data flow is Supabase-first: read from Postgres, fall back to the YouTube API only when the local catalog can’t answer, then write the result back so the next request is served locally. Redis provides a caching layer, BullMQ handles background jobs, and scheduled crons warm the cache and refresh video data outside of request paths.

There’s also explicit quota monitoring in the admin tooling, because on this stack quota is a resource you have to watch like memory.

Also built

  • Admin channel scraper for ingesting a channel’s catalog in bulk, plus bulk video management
  • Browse by category, channel and trending, with search
  • Video sitemap generation for search visibility on video content
  • Anonymous view limit of three videos before sign-in, using Clerk
  • A design lab of five complete theme variants — alpine, basecamp, fieldguide, ridge, summit — built to evaluate visual directions against real content rather than mockups

Scale

Roughly 250 source files, 51 pages and 35 API routes, deployed on Vercel with scheduled jobs running. Live, functional, and honestly better engineered than it is marketed — the caching and quota architecture is the part I’d point at.

Inside the project

1
watchtheoutdoors.com
The all-videos browse page with search, category filters and a grid of video results showing titles and channel names
Browse and search run against the local Postgres catalog rather than the YouTube API, which is what keeps the product inside its daily quota.

Questions about this work?

Happy to go deeper on any of it — the decisions, the trade-offs, or what I'd do differently.