DEV Community

Siddhraj
Siddhraj

Posted on • Edited on

I spent 6 months building an indie media tracker. Now a major platform shutdown turned it into a 48-hour scaling emergency.

Hey everyone,

I didn't just spin this up yesterday to chase a trending news topic. For the past six months, I’ve been quietly pouring my nights and weekends into coding an independent, non-commercial entertainment journal called ViewNote.

I built it out of pure frustration with two specific engineering issues: major tracking apps locking basic user analytics behind recurring subscription paywalls, and the absolute lack of native, granular episode-level TV show tracking in traditional movie diaries.

My architectural stack is clean and modern:

  • Frontend: Next.js 15 (App Router), React 19, Tailwind CSS
  • Database & Auth: Supabase (PostgreSQL with Row Level Security)
  • State Management: Zustand + a custom EventBus structure
  • Data Layer: TMDB API Wrapper Proxies

Everything was running smoothly in a quiet beta phase... until this weekend.

The 48-Hour Production Emergency

A few days ago, the massive media-tracking service TV Time announced it is permanently shutting down and deleting all user databases this Wednesday, July 15th. Suddenly, millions of television trackers are facing the permanent loss of 10+ years of curated episode watch logs.

My casual side-project instantly shifted into a high-stakes data rescue shelter.

I am currently pulling consecutive all-nighters to finalize a brand new asynchronous TV Time export file parser (.zip container handling bulk nested JSON/CSV strings) to map their historical timelines directly into my Supabase instance before their servers go dark on Wednesday.

The Architectural Challenge: The ID Translation Barrier

This is where the engineering gets messy. ViewNote relies entirely on TMDB IDs for cataloging metadata. However, TV Time's legacy platform relies on TheTVDB (TVDB) IDs for shows and IMDb IDs for movies.

To bridge this language barrier without melting my TMDB API proxy server limits during a multi-thousand-row data dump:

  1. The backend unzips the payload streams into memory.
  2. It aggregates data arrays by distinct tvshow_id keys to collapse 10,000 episode checkmarks down to 40 unique parent queries.
  3. It performs batch translation requests using TMDB's /3/find/{external_id} endpoint.
  4. It maps the timeline metrics and leverages supabase.from().upsert() with ignoreDuplicates: true to prevent disrupting existing user records.

I Need Your Engineering Eyes Tonight

Because I am a solo developer rushing this parsing engine into deployment against a ticking clock, I know there are edge cases, layout quirks, and format validation bugs inside the import code right now.

I am at a genuine turning point with this codebase. After half a year of development, I don't want this to turn into a dead repo. Should I fully commit to this infrastructure layout and build native mobile apps next, or is the market too crowded and I should archive the repository?

If you have a few minutes tonight, please pull your entertainment logs, head over to viewnote.online, play around with the data tools, and completely roast my architecture.

If you hit an infinite loading loop, break an importer routine, or catch a layout bug on mobile, drop it in the comments below. I am sitting at my desk with my Vercel logs and Supabase containers open right now to patch bugs live.

Thanks for supporting a independent dev fighting for open, portable data tools!

UPDATE (July 14): We are officially live on Product Hunt today! If you like independent, open-data engineering projects, I would deeply appreciate your support and feedback on our launch page

Top comments (0)