How this site is built
I ask clients to let me make architectural decisions on their platforms. It seems fair to show my working on my own.
Measured on the build that produced this page, not on a good day in a lab. The stamp at the bottom says which commit.
The constraint
A personal site has no traffic problem, no uptime requirement, and no team. That removes almost every excuse for complexity, which makes it a fair test: given no pressure to over-engineer, what does someone actually reach for?
Static output, no server
Astro builds to plain HTML and Cloudflare Pages serves the directory. There is no adapter, no server runtime, no origin to keep alive, and nothing to patch. Every page is on a CDN edge before the first visitor arrives.
The alternative — server-side rendering — buys personalisation and freshness. This site needs neither. Choosing the runtime you can justify rather than the one that is fashionable is most of what architecture is.
The storefront is hand-written
The catalogue, cart, and scope estimator are about 340 lines of vanilla JavaScript with no dependencies. A framework would have added a build step and a bundle to do work the platform already does.
This is not framework asceticism. It is the same judgement I would apply on a commerce platform: pick the smallest thing that solves the problem, and be able to say why when someone asks.
Content comes out of Obsidian
The writing is drafted in a personal knowledge vault, not in a CMS. An export step reads a single publish folder, validates frontmatter, resolves cross-links, and writes clean markdown into the repository on every commit.
The interesting part is the trust boundary. The vault also holds client work and daily notes, so publishing is opt-in by folder, a draft flag overrides it inside that folder, and the export prints exactly what is about to become public before it does. The same instinct as a deny-by-default integration: the safe path is the default, and the dangerous one is loud.
Fonts are self-hosted
Three typefaces, subset to latin and to the weights actually used, served from the same origin. The CDN version cost two extra DNS lookups, two TLS handshakes, and a render-blocking stylesheet on a domain outside my control.
The footer of this site claims it was designed to run light and load fast. A claim like that is checkable in about fifteen seconds with an open network tab, which is a good reason to make it true.
What I would do differently at scale
Almost all of it. Static output stops working the moment you need per-user pricing or real inventory. The hand-written cart would become a state machine with a real schema the first time a second developer touched it. Content in a git repository is excellent for one author and miserable for twelve.
None of those are reasons to build them now. They are the conditions that would tell me to.