Skip to main content

Why this exists

A birthday recap I never finished​

End of December 2025. My son's birthday was coming up and I wanted a recap of his year. I had hundreds of clips, all safely in Immich.

I opened Premiere, imported 40 clips, dragged them onto a timeline, added a few crossfades, realised I needed music. Two hours later I had 90 seconds of mediocre output and 360 clips I hadn't looked at. Never finished it.

Storage wasn't the problem (Immich handles that), and neither was finding clips (search works). The problem is the 4 to 8 hours between "I have 400 clips" and "here's a 3-minute film I'd show my family".

What it does instead​

It does the boring part. It connects to Immich read-only, looks at the period I pick and builds the film the way I would: find the stories in the period (a birthday, a weekend away, the ordinary weeks at home), give the big ones more room, keep the favourites, prefer a video when a video carries the moment, and keep everything in the order it happened. Then it renders it with titles, a map for a trip, and music.

All of that works on a plain NAS. A GPU describes every picture in the cut and double-checks what the family gets to see, and a model on top of it makes the cut better: it reads the draft and swaps out the shots that add nothing. What each one adds.

I still review what it picked. But I'm reviewing 30 pictures in a storyboard instead of scrolling through 400, and when it leaves one out, runs why says which rule did it. Every feature traces back to one manual step I didn't want to do again: that's why Live Photos get stitched, why a trip opens on a map, and why the music ducks under the clips' own sound.

If you run Immich, you already decided to own your pictures. This gives you something to do with them.

Built with AI, on purpose​

Claude and Codex write the code; I make the decisions, test the films and debug what breaks. The experiment is how far AI can go on a codebase this size while the code stays clean.

So far, guardrails are what make it work. Every PR goes through the gates in the Makefile (lint, types, complexity, a file length cap (800 lines warns, 1,000 fails), dead code, duplication, architecture boundaries, security scans, docs drift) and the build stays red until they pass. They catch real bugs that both models introduce with a straight face. The file cap forced a composition-based design with zero mixins, which turned out to be the right call anyway.

The judgement calls stay human: what a good film is, which rule is right, when a cut is good enough to ship. DISCLAIMER.md lists the gates one by one and where the approach fell short. How the product got its shape, and what broke on the way: How this was built.

What it isn't​

  • Not a video editor. You tick and untick pictures and cut again. There is no timeline.
  • Not a photo manager. It needs Immich and only reads from it, unless you ask it to upload the film back.
  • Not instant. The first cut over a period reads the pictures it can use; that work is banked, so the next cut over the same period is mostly the render.
  • No mobile app. A web UI that works in a phone browser, and a CLI.