How I built an AI movie tracker as a solo dev
I am a full-stack developer in the Netherlands, a bit over ten years in. For the last year my evenings have gone into one side project: I Like Movies, an Android app for tracking what you watch and deciding what to watch next. It went live on Google Play this summer. This is the honest version of how it got built, what the stack looks like, and the three or four decisions that mattered more than the rest. The problem was never finding a film Every movie app I tried was built for one person keeping one list. My actual problem was two people on one sofa, each with a watchlist, neither remembering which of us had saved the film worth watching. Picking something to watch with someone else is genuinely harder than picking alone, and no amount of better search fixes it, because search is not the bottleneck. Deciding is. So the app is organised around that. A household shares one library: one watchlist, one watched history, visible to everyone who lives with you. Add a film on your phone in the supermarket and it is on your partner's phone before you are home. That one feature is why the app exists, and it shaped almost every backend decision that followed. The stack, and why it is boring on purpose The backend is Go, GraphQL via gqlgen, and Postgres. The app is React Native with Expo. Film and TV metadata comes from TMDB. That is close to the most conservative stack you could pick in 2026, and that is the point. A solo project dies when the maintenance load exceeds one person's evenings, so every technology had to be something I could debug at 11pm without a second opinion. Go earned its place. The whole backend is one binary with no framework magic, and the type system plus gqlgen's generated resolvers mean a schema change breaks loudly at compile time instead of quietly in production. Postgres does everything: data, full-text search support, import staging. No microservices, no queue, no Redis. A single process and a single database will carry a consumer app much furthe