PopChoice

PopChoice began as my project for the Embeddings and Vector Databases module of Scrimba's AI Engineer Path. The course version proved a narrow loop: answer a quiz, embed those answers, search a catalog, and ask a model for the final pick. The technical goal was to turn that exercise into a product-shaped system; the product goal became helping someone stop searching.

Solo and duo are the primary use cases: one person faces endless browsing; two people face a loop of vetoes. Feedback from two frequent film viewers also made repeat avoidance important, which shaped Movie Memory. Version 0.2.0 lets visitors choose Fast Pick or Normal Match, then solo, duo, or a same-device group. A planned QR-room experience remains explicitly unfinished.

The course seed contained twelve films. I expanded it by roughly three hundred titles, including Soviet films for family testing, but that still could not support broad discovery. PopChoice now combines local PostgreSQL and pgvector retrieval with bounded TMDB discovery. Useful external candidates can enter the local index after identity and metadata checks, so the database becomes a reusable cache rather than the whole movie universe.

Constraints come before generation. Referenced, watched, rejected, and recently recommended films leave the pool before OpenAI ranks it. If the model returns an out-of-set title, deterministic code replaces it with the strongest valid candidate and a safe explanation.

Visitors can start a recommendation without creating an account. That keeps the first use lightweight, while a Redis-backed rate limit protects paid OpenAI work at the public boundary.

Submission first creates a result record and stable URL. BullMQ then reports real stages to that record, so reloads and sharing resolve the same lifecycle instead of restarting work. Failure is terminal in the browser; a later worker retry may require reload, while a fresh quiz creates a new recommendation. If the queue is unavailable, the server can process the persisted job inline without BullMQ retry.

Operations changed in three steps. Supabase let the course version ship, but its free database could sleep. Railway made a service-based setup easy, then grew to about $60 per month. Railway could have been optimized; I chose a Hetzner VPS with Coolify instead. It costs roughly a quarter as much, hosts more projects, and gave me direct deployment responsibility.

That move also added staging, source-controlled observability, and Telegram alerts. It is a practical first implementation, not a claim of mature platform expertise; deeper operational evidence remains a future deep dive.

I began this project as a frontend developer who had not worked directly with databases. It became my first substantial full-stack system and my first built mainly through AI-directed implementation. As features accumulated, product behavior, infrastructure, and request handling blurred together. I could abandon the project or rebuild its architecture; I chose the second path.

The refactor turned ownership into an explicit contract. The workspace separates the public app, internal tools, workers, services, and shared packages. Routes parse requests, feature modules coordinate product behavior, and integrations isolate external systems. These boundaries also give coding agents a map instead of one undifferentiated repository.

Fallow made the scale of the cleanup concrete. The first focused report for the web app found 103 dead-code findings, 194 duplicate groups, and 169 complexity findings. I treated those numbers as a map, not a deletion list. The later repo-wide pass reached zero actionable complexity and dead-code findings and an 87.9 (A) health score. A blocking new-only audit now gives every contributor—including agents—machine-checkable pressure against adding the same debt back.