John N. Fricker, Luthier Registry

Problem Statement

A luthier’s output is scattered by design: each instrument leaves the bench and lives with a different player, often for decades. What remains in the family is a box of build sheets, order correspondence, wood receipts, and photographs, plus the oral history of which guitar went where. Without a catalogue, that record decays — owners cannot verify provenance, researchers cannot study the maker’s development, and the next generation inherits an anecdote instead of an archive.

The Registry gives the workshop a permanent, citable home: one page per instrument, tied to its build records and photographs, with the maker’s biography and methods as context. It is meant to outlast the hardware it runs on and to be genuinely useful to an owner trying to confirm what they have.

Architecture & Technology Stack

The site is a fully static Astro build hosted on Cloudflare Pages. There is no database and no server on the read path; every instrument page is pre-rendered HTML and cached at the edge, which keeps it fast and cheap to keep online indefinitely.

Each instrument is a Markdown file with a typed frontmatter schema — model, year, serial, woods, dimensions, current known location, and an ordered list of image references — validated at build time so an incomplete record fails the build rather than rendering blank fields. Photographs are processed through Astro’s asset pipeline into responsive AVIF and WebP with explicit dimensions to hold layout stable. High-resolution scans are stored once and downscaled at build time.

Typography carries the project. The design uses a licensed serif for running text and a narrow display face for instrument titles, self-hosted as subsetted WOFF2 and preloaded, with a system fallback stack tuned to minimise shift. Fine rules, generous margins, and a restrained palette are meant to read like a printed catalogue raisonné rather than a web app. Dark and light themes share the same measure and rhythm.

Agentic Workflow Breakdown

The build followed the same spec-plan-phase loop used across the studio. Coding agents handled the scaffolding and the repetitive transformation work: defining the content schema from a sample build sheet, writing the image-ingest script that renamed and organised hundreds of loose scans against instrument ids, and generating the per-model index and cross-reference pages from the collection.

Because each instrument record is schema-validated, agent-assisted bulk edits — for example backfilling wood species or normalising date formats across every file — were safe: a mistake broke the build immediately. The human work was archival, not technical: transcribing handwritten build sheets accurately, deciding how much of a current owner’s identity to publish, and writing the biographical and methods essays in a voice true to the workshop.

Key Learnings & Next Steps

Static generation is the right call for an archive whose value is longevity. With no moving parts, the cost of keeping the Registry live for decades is close to zero, and there is no framework upgrade treadmill threatening the content.

Getting the content schema right early made everything downstream — bulk edits, new views, provenance updates — low-risk. The typography investment was not decoration; it is what signals to an owner that this is a serious record of their instrument.

Next steps: an owner-submission path so current players can contribute updated photos and location changes for review, IIIF-style deep zoom on the highest-resolution scans, and a printable single-instrument PDF generated from the same Markdown source.