← Projects

Project · Astro

jwsargent.me, this archive

The site you're on, a static Astro archive where adding anything is one Markdown file and one push.

Role
Design, build, words
Timeline
2026, ongoing
Status
Live
Scale
Static · $0 to run
Write one Markdown file, push once; the build fans it to the home index, the section pages, this page, and the terminal.Write one Markdown file, push once; the build fans it to the home index, the section pages, this page, and the terminal.

Why bother

Most personal sites die one of two deaths. They rot, because updating them is a chore you keep losing to actual work. Or they calcify into a brag wall nobody, including the person who built it, ever wants to touch again.

I wanted the opposite: a logbook I’d actually keep alive. Closer to a workshop bench than a résumé: a little messy, visibly in progress, cheap enough to ignore for a few months without guilt. So the brief I gave myself was small and stubborn: adding something new should cost one file and one push. Everything else is downstream of that.

One source of truth

It started as a set of design prototypes with the content hard-coded in two different places, once to draw the homepage index, again to feed the terminal. Two lists, same facts, kept in sync by hand. You can guess how that goes: they drift, quietly, until you don’t trust either one. That’s the exact rot I was trying to avoid.

So the rebuild has one source. Every entry (a project, an essay, a note from a trail) is a single Markdown file. From that one file the site generates:

  • the home index, in both its ledger and stream views
  • the section pages, and each entry’s own page
  • the terminal’s filesystem, the same files you can cat and open
  • the running counts (“4 projects”), derived at build, never typed by hand

Add a file, push, and it lands in all of those at once. There’s nothing to keep in sync because there’s nothing to sync. The schema even refuses to build if I fat-finger a field, which is the kind of nagging I actually want.

The terminal earns its place

A terminal on a personal site? I know how that sounds. But pull one up on any page, hit ⌘K, and it’s a real little shell: ls, cd, cat, tab-completion, command history, a filesystem that mirrors the site. You can dock it to an edge or float it loose and drag it around.

On a worse site this would be a gimmick, and I’d deserve the eye-roll. The one rule that keeps it honest: it’s purely additive. Everywhere the terminal can take you is also one plain click away in the normal nav. Nobody has to type a command to read an essay. It’s here because poking at a filesystem is genuinely how I think, and a personal site is the one place that’s allowed to be a little bit me.

Boring where it counts

The fun parts get the attention. The boring decisions are what keep it standing.

  • Static, end to end. It builds to plain HTML and serves off a CDN. No server to babysit, nothing to patch at 2am, and it runs for free.
  • Fonts self-hosted. No third-party requests, no handing every visitor’s IP to a font CDN, no part of the page waiting on someone else’s uptime.
  • Drafts are first-class. Half-finished writing sits in the repo flagged as a draft and simply doesn’t ship, so I can think in public without publishing in public.

None of that is clever. It’s the same unglamorous infrastructure I reach for at work, pointed at my own house for once.

Always a little unfinished

This is a working archive, not a launch. The whole bet is that if it’s easy enough to keep adding to, I actually will, a render here, a trail log there, an essay when the mood lands. If you’re reading this, you’re standing in the middle of it. Mind the sawdust.

1
content source, feeds the index, sections, pages & terminal
$0
to host, on a static CDN
0
third-party requests, fonts self-hosted

More from the archive