Photo Organizer

Every business that decides to do content lands in the same place eventually. It has more content than it knows what to do with. Professional creators spend a huge share of their time collecting, curating, and organizing their media. A small business creates content in passing, in between the actual work, and nobody is doing the curating. That's where we found ourselves at the farm.

Running a farm fills a camera roll faster than anything else I've done. Ours held more than 5,000 photos and videos, and they covered everything: B-roll in the fields, shots we hoped would become ads, weekly CSA updates, notes to ourselves on the status of a crop or a project, and photos of receipts and seed labels kept purely as records for our organic certification. Every asset made sense the day we shot it. Months or years later, finding the right one felt hopeless. Google Photos and Apple both have search, and both are incredibly limited. Neither could touch the questions I actually had, like "which of these are photos of multi-colored tomatoes taken at our farmers market booth in 2022?"

So I set off to build the thing that could. What I envisioned had three layers. First, a way to pull every asset we had into one place and fly through them fast, because even the best automated search eventually needs a human to look at some of it, and I wanted that to take an afternoon, not dozens of hours of hand-organizing. Second, a ridiculous amount of metadata about each one. Whatever the file already knew about itself, plus whatever a modern model could say about it: what's in the frame, what's being said, who it seems to be for. Third, one place to search all of that together, so anything I could think to ask would find its answer. What came out the other end is what I've been calling the farm photo organizer.

Building it started with a wall. I needed to get my photos, and they were in Google Photos. Google used to have an API for exactly that, reading down your own photos. As of 2025 it doesn't. Google removed read access to your own library, and Apple limits automatic photo downloading almost as hard. The reality of a modern photo hosting app is that they aren't your photos. They're the company's moat, the thing that keeps you from leaving, because they're hard to get out. So step one was getting them out. The one sanctioned bulk exit is Google Takeout, a mountain of zip files with the metadata scattered into JSON files alongside each asset and some filenames clipped where Takeout truncates them.

So we had a mountain of data, and I built a sidecar to run alongside it. The other option was the one most photo managers take, copying every file into a library of their own, but that doubles the size of the mountain and I didn't want a second one. The trade-off with leaving files in place is that they can move, get re-exported, or get dumped twice, and a database that tracks files by path loses track of them the moment any of that happens. I'll come back to how I dealt with it. On ingest the importer walks every file, reconciles the naming quirks, and extracts the EXIF.

So what goes in the database? First, whatever the files already know about themselves. Orientation, dimensions, whether a clip was a time lapse, geolocation, timestamps. The importer also writes a 400px WebP thumbnail for every asset straight into SQLite as a blob, 10 to 30 KB each, which sounds wrong until you see the payoff. The entire library's metadata, thumbnails included, travels as one file, and everything renders from it with no cloud round trip anywhere. The result is lightning-fast previews, and if you've ever tried to flip through thousands of photos you know how much a fraction of a second on every one starts to add up. Every organizing tool I've tried dies that same death. Flipping to the next photo takes a beat too long, and somewhere around asset two hundred you quit. Here I could scrub through the whole library in an afternoon, tagging assets by intent as I went, which is the one part of this a model can't do for you. I know which shots we'd put in front of a customer.

Where it got really fun was the second kind of metadata. A categorized library is useful, but photos still aren't very searchable. There are things you can do with image search, and none of them have proven terribly useful. Text search is fantastically useful. So what I needed was a way to encode the contents of every asset as text. Doing that by hand across 5,000 assets would have been a mind-numbing amount of work, and it's a perfect task for LLMs. It's one of the things they're uniquely good at. The two obvious moves were a description of every photo and video and a transcript of all the audio. Speech-to-text models transcribe every video. Vision models describe every image and clip. Optical character recognition lifts the text off labels and signs, which quietly makes those certification records findable too. Now every asset has text attached, and text is something I can search.

Once I had those transcripts and descriptions, I could combine them with the assets to ask new questions and create other kinds of enrichment. Does this video sound like it was meant for a customer? Does this read like a field report? Is there an insect in this photo? Each of those questions is a row in the database, a prompt template with an output schema and a default model, so a new one is a form fill rather than a script. All of a sudden I could answer questions like "which of these are photos of multi-colored tomatoes taken at our farmers market booth in 2022?" It worked like a charm.

One of the first real concerns with a project like this was cost. I was cognizant from past work that these models can get expensive fast, especially if you let them run amok, so I tackled cost in a few ways. One was choosing the right model, one that was cheap without being dumb. Another was compressing everything before it went to a model. And the last was making sure we never accidentally ran the same asset twice and paid for a pile of redundant metadata.

The model came first, and I started with one of my favorite models, Gemini 2.5 Flash. It's an absolute sleeper. It is not very smart, but it is smart enough, and it was the first model I ever used that could reliably look at a small pile of data and hand back a table or a specific fact without hallucinating. It's wicked fast. And it is dirt cheap, to this day probably the cheapest model on the market for the intelligence you get. Smart enough, fast, low hallucination, cheap. That combination is exactly what you want pointed at 5,000 assets. We described and transcribed the whole library for under $40.

Compression mattered most for video, which is where the money goes. Every clip gets compressed to a 720p, one-frame-per-second proxy before it meets a model. A description of a field doesn't need thirty frames a second of it, and the proxy costs a fraction of sending full footage.

Not paying twice comes back to the problem I set aside earlier. Files left in place drift, and a record keyed to a path breaks the first time one does. Photos are cheap, and the metadata I was stacking on top of them was not, so losing the connection between the two was the failure I most wanted to design out. The answer was to hash every file on ingest and key the metadata to the content itself. A photo can wander around the disk without losing what I paid for, the same photo from two dumps becomes one record with two known locations instead of two records that each get enriched on my dime, and an asset that has already been run for a given enrichment is skipped, never rerun, no matter where it turns up. Around that sits a set of guardrails so a mistake can't turn into a bill. Every batch prices itself up front from a per-model pricing registry, expensive runs wait for a second confirmation before they spend a token, and when a batch finishes, actual spend gets reconciled against the estimate so the estimator stays honest.

This project exceeded everything I meant it to be. It worked so well I added other models, so OpenAI, Anthropic, and Google now sit behind one abstraction built on the Vercel AI SDK, and I can pick a model arbitrarily and compare results. I can add human-created enrichments alongside the AI ones too. The models do the volume pass, then I review and fix what they got wrong. And like every tool I build now, it eventually grew an agentic search layer, so an agent can query the database and find what I'm looking for without me clicking through filters.

That was the whole point. I built this because I couldn't make sense of my own assets, and the reason I needed to was marketing. I was trying to run campaigns and I couldn't find the right content. So when we built our 2026 sales campaign, I queried for the assets I wanted, flipped through them, tagged the ones I thought would work for each campaign, and had my agentic assistant use the API to grab copies of all of them. A process that would have taken me days boiled down to about an hour. That campaign performed incredibly well, and I attribute a huge part of that success to being able to find the right assets to communicate what I was trying to say, which would have been a nightmare without this tool.

I can't overstate how handy this little tool has been on its own. But my big takeaway was finally getting my hands around a project that burned through real LLM API credits to build something useful, and coming out the other side confident I could use these tools in a way that was both safe and productive. As Uncle Ben said, with great power comes great responsibility. These models are wildly powerful, and they need checks and balances around them so that costly mistakes don't accelerate at the speed of AI.

To every business out there trying to make sense of a giant pile of content, know that there's hope. Ours finally stopped being a pile because it's now a searchable database. I've built flashier things than a photo organizer, but measured by how often it earns its keep, this is one of the most useful projects I've ever built. Maybe someday you'll be able to sign up and experience the same joy.