Archive Lens: a searchable catalogue for historical photographs

A friend collects and researches old photographs. Over time, the collection became a large Google Drive library of scanned images.

The files were stored safely, but the knowledge around them was scattered: names, places, dates, studios and research notes. Google Drive was already the right storage layer. The missing part was a searchable catalogue connecting the images to reviewed information.

I first tested local OCR extractors and a local worker flow. Keeping processing close to the files seemed efficient, but the OCR quality was inconsistent and the setup was too technical for the person using the tool.

Continuing towards a Windows application would have solved the wrong problem. I moved instead to a hosted browser workflow: connect Drive, choose what to process, review the output and search approved records.

Three decisions define the product.

Originals remain in Google Drive

Archive Lens stores Drive references, derived previews, OCR text, metadata and review state. It does not create another full-resolution copy of the archive.

Google Drive remains the source of truth for the original files.

Indexing and processing are separate

The user can index and browse Drive files before deciding which images should be processed.

This prevents every indexed file from automatically consuming OCR quota, processing time or storage.

OCR output requires review

OCR can suggest text, dates, places, names and studio information, but suggestions do not become approved catalogue data automatically.

A person must accept, correct or ignore the output.

The current MVP supports the main archive workflow:

1. Connect a Google Drive folder.
2. Index its files.
3. Select images for processing.
4. Temporarily process the originals through a Cloud Run worker.
5. Run Google Cloud Vision OCR and create derived previews.
6. Review the extracted text and metadata suggestions.
7. Move approved records into the searchable Catalogue.

The stack is React and Vite on the frontend, FastAPI for the API, Supabase Postgres and Auth, private Supabase Storage for derived assets, Cloud Run for processing and Google Cloud Vision for OCR.

To process Job events Processed

User flow System flow Processing flow

A historical archive can become large quickly, so processing is explicit rather than automatic.

The system separates Drive indexing from OCR processing, uses monthly OCR caps, processes originals temporarily and stores derived assets rather than duplicating full-resolution files.

Queue state, storage use and OCR quota remain visible. This is partly a cost decision and partly a product decision: the user should control when processing happens and understand what it consumes.

The project remains in active discovery.

Archive work contains uncertainty that cannot be resolved through OCR alone. Dates may be partial, names may refer to a subject, photographer or studio, handwriting may be unclear, and research may improve over time.

The next step is observing real review sessions and improving the review workspace, grouping, search and export around that behaviour rather than guessing what the workflow should be.

The value of the product depends on the review workflow, not the volume of OCR it can generate. Source files remain in Drive, processing is deliberate, and catalogue knowledge becomes authoritative only after human review.