Building AR/146 as a Static Personal Index

Starting with the shape of the problem

I did not want this site to behave like a list of finished projects. A project grid is useful when every item has the same shape, but my interests do not fit one shape. A technical decision, a long essay, a short observation, and a sequence of images ask for different reading speeds.

The first design question was therefore not “What should the home page look like?” It was “What kinds of things should this place hold?” That question led to seven content types: work, essays, notes, photography, trails, topics, and dated Now updates.

Each type has its own purpose. Work records explain decisions and constraints. Essays develop an argument. Notes hold smaller observations. Photography uses sequence and captions. Topics reveal durable threads. Trails provide a deliberate order across formats. Now records keep the index connected to the present without turning the whole site into a feed.

Choosing a static public surface

The public site does not need an application server. Most of its work can happen during the build: reading content, resolving relationships, preparing images, and producing HTML. Astro fits that shape well.

This choice is more than a performance decision. A static output has a smaller operating surface. The site can be hosted as files, remains readable when scripts fail, and does not need visitor accounts or a database. It also creates a useful design constraint: an interaction must earn its JavaScript.

Search, filters, theme preference, command navigation, and photography focus mode use small client scripts. Reading and navigation do not depend on them.

Designing for relationships

The index becomes more useful when one record can lead to another for a clear reason. A shared topic can reveal a connection that was not obvious from format alone. An explicit related link can preserve an important path. A trail can turn several records into an ordered reading experience.

These relationships use stable pairs of content kind and slug. The build resolves them before publication. If a reference is broken, points to hidden material, or creates a circular trail, verification fails. The page never guesses around a broken relationship.

Keeping the visual system quiet

The design uses type, spacing, rules, and sequence before decoration. Editorial type carries the main reading hierarchy. Interface text stays plain and compact. Terracotta appears as a limited accent instead of a constant signal.

This restraint matters because the content changes form. A photograph should have room to lead. A short note should not look unfinished. A detailed work record should remain easy to scan. The shared system holds these differences together without forcing every page into the same card.

What this work produced

AR/146 now has a static route system, typed content, public discovery, RSS and JSON feeds, a sitemap, local search data, responsive layouts, print styles, and deliberate empty states. The administration route and its authentication worker remain separate from the public bundle.

The important outcome is not the number of routes. It is a structure that can grow without losing its publishing rules. New material can be added slowly, reviewed in context, and connected to what is already here.