The Stack

🚧 WIP

What and Why?

A cross-platform media tracker for movies, TV, books, and games, built solo as a passion project by a senior product manager.

The Stack is a dark-mode-first app for tracking everything you're watching, reading, and playing in one place. Instead of juggling separate systems (or a Notes app) for movies, TV, books, and video games, it uses one universal vocabulary, Pending / Done, across all four, so the same simple interaction works everywhere. It's built for iOS, Android, and web from a single codebase, with a full web, App Store, and Google Play release as the goal.

I'm building it myself, end to end, for two reasons:

  1. The app itself. I wanted a tracker that actually matches how I think about remembering which media I want to check out, like one shared to-do list.

  2. The process. This is also a firsthand experiment in what an AI coding agent can do entirely on its own versus where a senior product manager's judgement adds true value: sequencing the work, catching tradeoffs an agent won't flag unprompted, holding one coherent architecture together across hundreds of small decisions, and painstakingly trying to break everything during QA.

The rule I set from day one: understand how the pieces fit together and how the code works rather than execute blindly. Every architectural choice (the data model, the backend, the accessibility commitments) is one I can explain and defend, not one I accepted on faith from a tool. That discipline shapes everything below:

  • Favour the least complexity that still respects the full product vision.

  • Build the expensive-to-retrofit things (data model, internationalization/localization, accessibility) correctly from the start rather than undertaking wild refactors later.

Under the Hood

  • Frontend: React Native + Expo (SDK 54), chosen specifically because it runs in Expo Go for instant on-device preview with no native build required during early development.

  • Design system over custom components: UI is built entirely on gluestack-ui v3, composing its stock components rather than writing one-off, bespoke styled elements. Design tokens (colour, spacing, typography) are extracted directly from Figma variables, not eyeballed from screenshots, and mapped into a single semantic token system that's dark-mode-first but built to support light mode without a future rewrite. Figma and the codebase share one source of truth, so a design decision only has to be made once.

  • Backend: Supabase, chosen for Postgres over a NoSQL document store, because the data is inherently relational: type-aware items with per-type fields, statuses, and tags that need to be queried and filtered across types. Row-Level Security enforces "users see only their own stack" at the database layer, and Supabase's Anonymous Auth means people can use the app fully (add, track, browse) before ever creating an account.

  • Data sources: TMDB (movies/TV), IGDB (games), and Open Library (books), normalised into one common item shape so search and storage never branch by media type.

  • Supporting layers: TanStack Query for caching and perceived-instant search and offline resilience; i18next for English/Spanish from day one; Amplitude for product analytics, wrapped behind a single helper so the SDK can be swapped without touching the rest of the app; RevenueCat for a one-time, non-gating, totally optional "Support the Dev" contribution in the future. The app itself stays entirely free for the end user, and the costs come from my "fun money" budget. RIP takeaway food.

  • Accessibility: treated as a first-class, day-one commitment (aligned with WCAG 2.2 AA and the EU's Accessibility Act) rather than a pass at the end, including screen-reader labels, proper touch targets, and a rule that no action is ever gesture-only.

How It Gets Built

  1. Design direction: Figma (the Obra shadcn/ui kit) defined the tokens and layout direction for the foundation phase. It was deliberately never treated as a pixel-perfect spec: every screen still had to be translated into real gluestack-ui v3 components, since Figma's raw values don't map one-to-one onto what the library actually ships.

  2. Designing beyond the foundation: Figma earned its keep establishing the component vocabulary and the discipline of mapping every design decision to something the code library actually offers. But once that design system existed, mocking new screens in Figma became double work — designing in one tool just to translate it into another. Newer flows (search, the media card) skip it entirely: Cowork sketches interactive layout options directly from the established tokens and components, I pick and push back like I would in a design crit, and the winning option is written straight into the ticket as the spec. Design stopped being drawing and became composing known parts — and the real mockup tool is the app itself, hot-reloading on my phone.

  3. Spec discussion: specs get settled in Cowork, deliberately outside the coding agent. For the foundation phase that meant using the Figma MCP connector to pull the kit's real defined variables and component structure (not approximated from a screenshot) and mapping each one onto an actual gluestack primitive. Now it means talking through options and tradeoffs — layouts, interaction patterns, edge cases like "what does a screen reader hear?" — until a decision exists that's worth writing down. Either way, the output is the same: a written spec the coding agent can build from without ever needing its own opinion about design.

  4. Ticket handoff: once a spec is settled, Cowork writes it into the living design-system reference doc and, connected to Linear via MCP, opens a scoped ticket from it, one ticket per build step rather than per line of code.

  5. Build: Claude Code, running in Zed's integrated terminal, builds directly from that ticket, doing the actual coding, refactoring, and git operations. It never needs its own Figma connection; it builds entirely from the written spec. Zed itself is the cockpit for reviewing diffs and navigating files.

  6. Shipping: everything lives in a private GitHub repo, deployed in the future via EAS for mobile, and, once the web app gets out of local development, likely on Vercel.

The result is a project that moves at the pace of one person building on the side, but with the architectural discipline of a team that plans before it builds: every decision logged, reasoned about, and revisited only when new information actually warrants it. It's also, quietly, a running log of where an AI agent is genuinely capable on its own and where it still needs a product leader protecting the bigger picture and the end user experience.