Jonas ForshellSenior Product Owner
jonas@jforshell.seEmail me
Working buildUser testingCase · Own build

Archive Lens, a historical photo catalogue

A friend researches old photographs. The files were safe in Google Drive. The knowledge around them was scattered across names, places, dates, studios and research notes. Archive Lens is the catalogue that connects the two, without moving a single original.

Context
Historical photograph catalogue
Role
Product Owner and builder
Stage
In user testing with its first real user
Stack
React, FastAPI, Supabase, Cloud Run, Google Vision

The short version

The problem
A friend researches old photographs. The files were safe in Google Drive, but the knowledge about them was scattered.
What I did
Designed and built a catalogue that connects the two. OCR suggests, a person approves.
What it was worth
A hosted product in user testing with its first real user, with cost and processing under deliberate control.
The call
Originals never leave Drive, and nothing becomes catalogue data until a person agrees with it.

Easier to watch than to describe

Eight screens, no sound, thirty five seconds. Today, the catalogue, a search matching text read off the back of a card, a reverse waiting for approval, an album page boxed into four photographs, a run in flight with two failures explained, the Drive folders being watched, and AI spend against its ceiling.

Built from the product's own screen captures rather than a screen recording, so it re-renders identically every time the interface changes.

From local experiment to hosted product

I started with local OCR extractors and a local worker. Keeping processing next to the files looked efficient. The OCR quality was inconsistent and the setup was far too technical for the person who would actually use it.

Continuing towards a Windows application would have solved the wrong problem well. I moved to a hosted browser workflow instead. Connect Drive, choose what to process, review the output, search what has been approved.

This is an AI build. Claude and Codex wrote essentially all the code. My part was the product. Scope, decisions, review and testing.

Three decisions define the product

The boundaries
  1. 01

    Originals stay in Drive

    Archive Lens stores Drive references, derived previews, OCR text, metadata and review state. It never makes a second full resolution copy. Drive remains the source of truth.

  2. 02

    Indexing is not processing

    You can index and browse Drive files before deciding what to process. Nothing quietly consumes OCR quota, processing time or storage just because it exists in a folder.

  3. 03

    OCR output is a suggestion

    OCR can propose text, dates, places, names and studios. None of it becomes catalogue data until a person accepts, corrects or ignores it.

The workflow as it stands

  1. Connect a Google Drive folder.
  2. Index its files.
  3. Select the images worth processing.
  4. Process the originals temporarily 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.
Archive Lens dashboard showing archive counts, queue health, storage use and OCR quota
Queue state, storage use and OCR quota stay visible on the dashboard.
Archive Lens review queue showing records waiting for review
The review queue is where a person accepts, corrects or ignores what OCR found.
Archive Lens processing view showing a run in flight with failures explained
Processing is modelled as explicit stages, including the failures and the retries.
Archive Lens AI cost view showing spend against the monthly cap
AI spend is shown against its monthly ceiling rather than discovered later.
Archive Lens user flow from Drive Sources through Processing, Review Queue, Catalogue, Export Wizard and Settings
The user flow from Drive connection to reviewed catalogue record.

Cost is a product decision, not a footnote

A historical archive gets large quickly, so processing is deliberate rather than automatic. Indexing is separate from OCR, there are monthly caps, originals are processed temporarily, and only derived assets are stored.

Queue state, storage use and quota stay visible. Partly that is about cost. Mostly it is because the person using it should decide when processing happens and be able to see what it consumes.

What still has to be proved

The project is in active discovery, and the uncertainty in archive work cannot be resolved by OCR. Dates are partial. A name might belong to the subject, the photographer or the studio. Handwriting is unclear. Research improves over time and the record has to be able to change with it.

The next step is watching real review sessions and shaping the review workspace, grouping, search and export around what actually happens, rather than what I imagine happens.

The value of this product is the review workflow, not the volume of OCR it can generate. Source files stay in Drive, processing stays deliberate, and catalogue knowledge only becomes authoritative after a person has agreed with it.