BingeBuddy Roku app

The product problem

Streaming discovery is usually optimized for browsing, not deciding. BingeBuddy was designed around a narrower job: capture a viewer's services, mood, and watch-party context, then return a useful short list on Roku.

That required more than a recommendation endpoint. The product needed a Roku interface, a web companion for account setup and device pairing, durable profiles, provider-aware availability, and a way to prove that the packaged channel still matched the hosted API.

The system

I built the product across a Roku SceneGraph channel, a React companion, and a TypeScript/Fastify API backed by PostgreSQL. The API owns profiles, pairing, recommendation sessions, feedback, and device events. Watchmode supplies catalog and availability data, while the recommender produces the final ranked slate and watch calls to action.

AI has a deliberately limited role. It can turn a natural-language prompt into structured intent, but it does not invent availability or directly control the final order. The same flow has a deterministic fallback when a model call is unavailable.

Making the beta testable

The release workflow covers the hosted API, companion voice flow, Roku package provenance, pairing, provider persistence, recommendations, feedback, and post-install acceptance on a real Roku. The retained proof artifacts show a current package successfully side-loaded and exercised against the production API, including Watchmode-backed picks and observed intent extraction.

That evidence matters because a passing API test does not prove a television product is usable. BingeBuddy's gate connects the package hash, hosted behavior, and device acceptance so each release can be traced to what actually ran.

The takeaway

BingeBuddy demonstrates an end-to-end product approach: a focused consumer experience, narrow and accountable AI, cross-device state, and release evidence that reaches beyond source-level tests.