A man approaching eighty, retired from a long career in military and government research in North Alabama, called with a request we don't get often. He had spent a lifetime writing — technical papers from his professional years, all unclassified; essays; a book; screenplays; illustrated stories and cartoons he'd made for his grandchildren — and he had more than three hundred documents he wanted in one place, organized his way, where his family and a small circle of colleagues could find them for years to come. He was very clear that he wanted it custom, that he wanted it exactly as he described it, and that he did not want to learn anything new to run it.
His specification was the most precise we've ever received on a first call. White background. Black letters. No graphics, no color, no video, no templates, no search engine optimization, no selling, no comments or interaction of any kind. Three levels of navigation — a main menu, a chapter, a document — with breadcrumbs at every level so a reader could always find the way back. He would add the documents himself.
He had tried once before, with a commercial website platform, and given up.
What he asked for, and why it would have failed
What he actually asked for was a static set of HTML pages with numbered placeholders he could fill in himself. It is a reasonable request from someone who has been burned by a platform that kept trying to help, and the fastest thing we could have done was build it. It also would have failed him within a month.
Three hundred documents across ten chapters is not a template problem. It is a management problem. Every new document would have meant editing a page, uploading a file by hand, fixing a link, and keeping the chapter listings in order — exactly the kind of fiddly, abstract technical work he had told us he would not do. The commercial platform had failed him for the opposite reason: it imposed design, structure, and features he had explicitly rejected, and made the simple thing hard by surrounding it with everything else.
The right answer sat between the two: a small, purpose-built system with a public side that was exactly the stark, text-only archive he described, and a private side built around the three or four things he would actually do — upload a document, name it, put it in a chapter, decide where it sits in the list. Nothing else.
That reframing was the hardest part of the project. Explaining to a client who asked for a template why he was getting a database and an admin panel, in terms that landed as "simpler for you" rather than "more complicated," took care. He accepted it because the alternative had already failed him once.
What we built
The public archive is as plain as he asked. White page, black serif type, a monospaced label face for navigation, no images except the ones that are the documents. Three levels — menu, chapter, document — with clickable breadcrumbs on every page. It is hidden from search engines three separate ways, because he did not want strangers finding it and a single setting is easy to lose in a migration.
The admin panel is a password-protected page where he uploads a file, gives it a title and an optional subtitle, chooses the chapter, and adds an introductory note if a reader will need context before opening a technical paper or a screenplay. That description field was not in the original scope; it was added after a call in which he explained that some of his documents make no sense without a paragraph of setup. He was right.
The file handling makes decisions so he doesn't have to. A PDF of fifty pages or fewer opens in a page-turning viewer right on the page. A longer one gets a download button instead, automatically, because nobody reads a two-hundred-page document in a browser frame. Word documents open in an inline viewer with a download fallback. Images display directly. The system counts the pages on upload and chooses the display mode; he never sees a setting.
Reordering got rebuilt mid-project. The first version had a sort-order number on each document — type a 3 and it goes third. For someone who thinks in documents, not integers, that was too abstract, and he reported that he could not make it work reliably. We built drag-and-drop: a grab handle next to each row, pull it where it belongs, it saves when you let go. The number field is still there for anyone who wants it. He uses the handle.
Small things that turned out to matter. PNG support was added the day he tried to upload the cartoons. The document viewer was widened after he mentioned a panoramic group photograph that deserved the room. When a book of twenty-seven chapters came up, the answer was not a new feature: split it into twenty-seven files, one per chapter, and the archive already does the rest.
And the question most projects never ask. He wanted to know what would happen to the archive after he was gone. That is not a hypothetical for a man building a legacy; it is the point. We structured the hosting as a multi-year prepaid arrangement on a server we control, with a written commitment that if anything changes on our end, unused time is refunded or the site is handed over intact. The infrastructure is deliberately boring — standard web stack on a dedicated slice of a server, automatic certificate renewal, an isolated database — because boring is what lasts.
What happened
He uploaded eighty documents in his first week with access. The archive is in daily use by him and shared with family and colleagues of his own generation, which is its own test: an interface that works for a reader in his late seventies who has never used an admin panel is an interface that works. The technical papers have their introductions. The grandchildren's cartoons are in their chapter. The twenty-seven-chapter book is navigable by chapter.
And the project took roughly twice the hours the build itself required, because a client who discovers what he needs by using the thing — and who writes to tell you — is a client whose project matters to him. We priced the build, and we learned to scope the conversation too. Deciding that deliberately beats discovering it afterward.
What we'd tell the next person
Ask about the navigation hierarchy on the first call, specifically: do all sections have subsections, and are those subsections navigational levels or just visual groupings? That question would have saved two rounds of email here. Build the intuitive version of any abstract control before you're asked, because a non-technical client will hit the wall and you'll build it anyway. And when someone is making something meant to outlast them, treat hosting and ownership as part of the scope, not the fine print.