How to Build Something Right — A Letter, a Website, a Method
A 165-year-old letter from a French soldier sparked a website project. But the more interesting story is the discipline we used to design it — and why that discipline matters especially when your collaborator is an AI.
This post is addressed partly to my son, who is beginning to use AI tools for coding, and who asked how I approach projects like this one. The short answer is: with a methodology borrowed from professional software development, applied even to small personal projects. The longer answer is what follows.
The project itself started with a remarkable discovery — a handwritten letter, dated February 25, 1860, written aboard a French naval transport called Le Jura as it rounded the Cape of Good Hope. The author was Louis Clergerie, a young artillery soldier on his way to fight in the Second Opium War in China. The letter is in the possession of Annie’s family. It is vivid, funny, sad, and historically precise. It deserves to be seen.
The goal: a small, elegant website at michaeldbush.org/clergerie that presents the letter, its transcription and translation, the historical context, and a guide for continuing the genealogical research. Simple enough. But simple goals still deserve careful design — especially when you are building with AI.
Why Methodology Matters More with AI
When you work alone, your unspoken assumptions live in your head and travel with you. When you work with another person, you negotiate them out loud. When you work with an AI, something different happens: the AI has no persistent memory of your project between sessions, no stake in the outcome, and no way to push back on a vague brief except by guessing what you meant.
This means that the quality of your output is directly proportional to the quality of your specification. An AI given a vague prompt produces vague code. An AI given a precise, agreed specification produces precise, coherent output — and can be held to it across many sessions.
“The specification is not bureaucracy. It is the shared memory that makes sustained, coherent collaboration possible.”
The methodology we used here has three phases, executed in strict sequence. No coding begins until both specifications are approved. This feels slow at first. It is not. It saves far more time than it costs by eliminating the most expensive kind of rework: discovering, halfway through coding, that the design was wrong.
The Three Phases
Functional Specification
What does the site do? Who is it for? What pages exist, what does each contain, how does the user move through it? What is explicitly out of scope? This document answers every what question without touching any how. It is written in plain language, not code. A non-technical family member should be able to read it and say whether it describes the right thing.
Technical Specification
How will the site be built? What technology stack, what file structure, what CSS architecture, what JavaScript behavior? This document translates every decision in the functional spec into a precise engineering plan. It includes the SVG map’s confirmed waypoints, the exact CSS custom properties, the lightbox behavior down to keyboard navigation — everything a developer needs to code without guessing.
Coding
Only now does code get written — against a target that has been agreed, reviewed, and approved. Changes are still possible, but they require conscious decisions, not drift. The AI codes to the spec; deviations are flagged, not improvised. The result is a codebase that reflects intentional design rather than accumulated decisions made under pressure.
What the Specifications Contain
For this project, the Functional Specification runs to several pages and covers the site’s purpose and audience, a complete content inventory of every document and image, the structure of all seven pages, the visual identity (color palette, typography, layout principles), every functional requirement from the letter viewer to the print stylesheet, accessibility standards, and a list of six explicit open questions that needed answers before the technical work could begin.
Those questions — things like “subdomain or subdirectory?”, “side-by-side or tabbed letter viewer?”, “what should the site be called?” — were answered by the client (me) before the technical specification was written. This is the right sequence. Design questions answered by the client; engineering questions answered by the technical spec; coding questions answered by the code.
The Technical Specification then makes every engineering decision explicit: the file structure down to individual filenames, the CSS custom properties with their exact hex values, the confirmed itinerary of the Jura‘s voyage for the SVG map (ten waypoints, from Toulon to Tché-fou, including the Japan horse-buying excursion confirmed in a 1860 French military document), the lightbox behavior, the language tab switcher implementation, the image preparation commands, the deployment procedure, and the recommendation to develop on ELMORE and serve from Alabama.
Both documents are linked below and are worth reading as examples — not because this is a large or complex project, but precisely because it is small. The methodology scales down cleanly. A weekend project benefits from a one-page functional spec just as a six-month project benefits from a fifty-page one.
Functional Specification — The Louis Clergerie Letter Website Purpose, audience, page structure, design identity, functional requirements, and open questions. The what before the how. Technical Specification — The Louis Clergerie Letter Website Technology stack, file structure, CSS architecture, SVG map design, letter viewer behavior, deployment procedure, and server recommendations.What This Looks Like in Practice
The conversation that produced both specifications ran for several hours across a single session. It began with a search for historical information about a French naval transport and ended with a complete engineering plan for a seven-page website. Along the way: a transcription of four pages of 19th-century French cursive handwriting, a Word document with full historical analysis, a confirmed list of waypoints for the ship’s voyage from French military records, and the discovery that Louis Clergerie’s unit — the 3rd battery of the 10th Marine Artillery Regiment — is specifically named in a 1860 French military study of the China campaign.
None of that research was planned at the start of the session. It emerged because the conversation had a clear purpose — understand Louis Clergerie well enough to present him honestly — and because the specification process forced the right questions to be asked before the building began.
Write the functional specification first, always. It forces you to decide what you are actually building before you start building it. With an AI collaborator, it does something additional: it creates a shared reference document that both of you can return to across sessions, ensuring that the tenth hour of work is as coherent as the first.
Do not skip the technical specification to save time. The technical specification is where you discover the hard questions — the ones that would have stopped you cold in the middle of coding. Better to discover them on paper, where they cost nothing to answer, than in code, where they require rework.
This methodology does not guarantee good results. It guarantees intentional results — outcomes that reflect decisions you actually made, rather than decisions that were made for you by inertia, by the AI’s defaults, or by the path of least resistance. Whether those decisions were right is still your responsibility.
The Site Itself
The website is now in the coding phase. When it is complete, it will live at michaeldbush.org/clergerie and will include the original letter scans, the full French transcription with English translation, a stylized SVG map of the Jura‘s voyage from Toulon to Shanghai, a summary of the China campaign drawn from contemporary French military sources, and a practical guide for anyone who wants to continue the genealogical research into the Clergerie family.
Louis wrote his letter at the Cape of Good Hope, two months and fourteen thousand kilometers from home, to parents he was not sure he would see again. He described a matelot who fell from a yardarm and was lost at sea, the baptism ceremony crossing the equator, the taste of salt beef on Mondays. It is an extraordinary document. It deserves a good home.
This post describes a project in progress as of May 2026, developed in collaboration with Claude (Anthropic). The functional and technical specifications linked above were produced in a single research and design session. Coding will proceed on ELMORE (Ubuntu 24.04) using Claude Code, with deployment to Alabama (Raspberry Pi, Apache). The letter of Louis Clergerie is in the possession of the Bush family. The historical research draws on the Scherer study of French artillery in the China campaign of 1860 (artillerie.asso.fr) and the archives of the Service Historique de la Défense.