Memrey
The problem
Every family has a hard drive with thirty thousand photographs on it, and nobody has ever looked at photograph number 14,206.
The archive exists. The memory doesn't. Consumer photo tools solved storage a decade ago and then stopped. They can find you a dog, a beach, a screenshot. They cannot find you the afternoon my dad taught me to drive, because that isn't a label — it's a memory, and memories are made of people, places, weather, time of day, and the thing that happened right before and right after.
What I built
- An ingest pipeline that swallows decades of mixed media — phone dumps, scanned prints, tape rips — without asking anyone to organise anything first.
- A memory graph instead of a tag list. People, places, events and time are first-class entities with relationships, so a query can travel between them.
- Natural-language retrieval over embeddings, grounded against that graph, so a vague human question returns a specific, correct set of frames.
- An interface my dad can use. The whole thing lives or dies on whether a sixty-eight-year-old can type a sentence and get their life back.
Architecture
One query, all the way down
This is the whole product as a single object. A sentence goes in the top. Every hop it makes to find the answer is on the page — because the interesting part of this system isn't any one stage, it's that they compose.
Pull the entities out of a sentence nobody wrote for a machine.
Resolve them against the memory graph. This is the step every other photo tool skips.
Search the embeddings for anything that looks like the sentence.
Rerank the vector hits against the graph. Keep only frames with person_14, inside the window, at one of the three events.
It gets this right when the person is in the graph. It gets it wrong when the memory belongs to whoever was behind the camera — the one person who is never in the photograph. I haven't solved that one yet.
Three things I didn't build
Because embeddings return photos that look like what you asked for. A memory isn't a similarity, it's a relationship. Vectors find you a beach. The graph finds you that beach, with those people, on that day.
Because one engineer cannot operate two databases. Postgres with pgvector holds the graph and the vectors in one place, with one backup and one failure mode. The right architecture is the one you can still run at 2am.
Because a family archive is thirty thousand photographs, not thirty million. There is nothing in it CLIP doesn't already know. The value was never in the model — it's in the graph I built around it.
The interface
Hard crops of the real thing at poster scale — the product as it actually looks, not a browser-chrome mockup.
These are the numbers I can stand behind today. When the beta opens I'll replace them with the ones that matter — corpus size, recall, and how often the first result is the right one.