Sorry, this product is behind a login! Happy to give you a full walkthrough in a chat. In the meantime, there’s a ~70-second demo below, under “What I built,” and screenshots throughout if you’re curious.
The problem
Two people, 5+ subscriptions, and the same stalemate every night. Streaming catalogues are enormous, each partner’s taste pulls in a different direction, and the hardest thing to find is the overlap in taste, the show you’ll both actually enjoy. Recommenders are built for one viewer, not for two people deciding together.
Who it’s for, and why it matters
A multi-person household that watches serial TV shows together and separately, and wants the decision made for them instead of doom-scrolling and debating for twenty minutes.
The problem loop
This debate of ‘what to watch next’ leads to frustration and acts as a time sink when you could already be watching something. The flow below shows the difference between the current behavioural loop and the proposed solution.
What I built
A web app that tracks what each partner has watched, is watching, dropped, or wants to watch, then generates three ranked recommendation lists through Claude Haiku or Sonnet (user setting):
- Co-watch: shows both partners would likely enjoy together
- Corey’s Picks: personalized for one partner
- Jaimie’s Picks: personalized for the other
Lists cover both new shows and continuations of in-progress series. Each partner votes Agree / Disagree / Maybe on every pick; votes are visible to the other partner and feed back into the next round of rankings. Every recommendation comes with a short personalized why, not just what.
For more focused recommendations, a user can adjust the generative prompt and produce a list weighted towards a specific genre, subscription or mood.
▶ Demo · the recommendation loop
How it works
The model reasons over multiple variables to produce a ranked set of shows for each list. These inputs include:
- Each partner’s watch history and ratings → Taste
- Current status of in-progress shows → Recency
- Active streaming subscriptions, including regional availability → Access
- TMDb community ratings → Importance
- Episode counts → Required Investment
- (Optional) Mood / Genre → Contextual Feeling
The “co-watch” list is the interesting part: it optimizes for joint enjoyment, which is a different objective than “what would this one person like.”
Stack & architecture
Next.js 16 (App Router, React Server Components, Server Actions) with Prisma (SQLite locally, Postgres in prod), passcode auth via iron-session, the Anthropic SDK for generation, and the TMDb API for metadata, posters, and streaming providers. UI in Tailwind v4 + Radix. Built and deployed solo.
How I measure success
The app instruments its own feedback loop, so success is observable rather than guessed. These are early, first-pass targets set before there’s much real signal, and meant to be revised as usage builds.
The north-star metric is watch-through rate: how often a recommended pick actually gets watched. Given everything that goes into choosing a show in the moment (time commitment, other shows in progress, mood), a credible first-pass bar is ~50% watch-through within the top 20 recommendations: the right show is usually somewhere in the shortlist.
Supporting signals:
- Agreement rate: share of recommendations voted “Agree” (built-in voting). First-pass target: ~60% across the ‘co-watch’ top 10.
- Time-to-decide: minutes from opening the app to choosing something. The whole point was killing the twenty-minute scroll.
- Repeat usage: do we actually come back to it each week.
- API costs: can I run it for less than a flat white a month?
Product takeaways
- The biggest learning was that this is a low-frequency product. You only really need it between shows. That cuts both ways: real signal on what’s working accumulates slowly, so iteration and improvements are non-obvious; but ongoing cost and user overhead stay minimal.
- Recommending for a pair of users is a genuinely different problem from recommending for an individual. The win is in the overlap, and optimizing for it changes both the data you collect and how that data is weighted, as well as how you rank.
- The explanation (“why this show”) built trust more than it signalled ranking quality. The generative reasoning behind a recommendation did not necessarily improve the likelihood that you would pick it, but it helped the user understand why it was on the list, building credibility.
- Closing the loop with lightweight voting was a much stronger signal and turned a static suggestion list into something that improves with use, for almost no added UI complexity. Especially for shows that eventually get categorized as ‘watch later’.
- The largest challenge with this product was data availability, which drove risks to usability and adoption. Users’ active subscription watch histories are not publicly available, making initial setup and ongoing maintenance costs high for the user.
- I did explore alternatives: Netflix offers a CSV watch-history export, but it covers only one subscription and is manual, so it added complexity without solving the problem.
What’s next
- Continue using the product to further assess what is working and what is not.
- Review API costs to build a better understanding of ongoing costs and if bumping to an improved model fits within the budget
- Future feature iterations (tech feasibility aside):
- Embedded trailers for shows to increase confidence in show selection
- Direct links to a show in its streaming app to reduce decision-to-action friction. Currently, once you select a show, you still have to open the app and search for it
- Confidence scores on recommendations. How confident is the model that the user or users will agree with this recommendation?
More of the product
