Skip to content

kolophōn, from the Greek for finishing stroke. A colophon is the note traditionally placed at the end of a book describing how it was made. This page is the digital equivalent: a record of the technologies, design decisions, and engineering behind this site. That is why it is not titled “About this site.”

How this site is built

What the site is built from, and why each piece is there.

01 — Stack

Next.js 16, App Router
Static generation covers every route. Dynamic rendering requires a stated reason, and no route currently has one.
React 19 with the compiler
Manual memoization is absent by default. React Compiler handles the common cases; profiling determines whether an explicit escape hatch is needed.
Zero client components
Every file is a Server Component. Each candidate island was rejected with a reason recorded in the file rather than in a commit message.
A persisted theme control
System, light, and dark remain three radio inputs read by CSS. A small inline script stores an explicit choice in localStorage and restores it before first paint, without adding a client component.
MDX parsed by about a hundred owned lines
gray-matter plus Zod. A content library would save those lines and cost understanding of the build.
Biome, plus ESLint for the compiler rules only
One fast formatter and linter. ESLint survives solely for the React Compiler diagnostics, which Biome does not implement.
No database, no CMS, no analytics
Content is files in git, reviewed by diff. Nothing is collected from visitors.

02 — Datum

Datum takes its name from the fixed reference plane used in aircraft design to calculate structural coordinates, measurements, and weight balance. It serves the same role here: the system's zero point. The visual language uses warm paper tones, restrained monochrome surfaces, a single instrument color, and the IBM Plex family for display, body, and data. Color relationships were calculated for consistency and contrast rather than selected by eye.

PairRatioLevel
Ink on paper14.70AAA
Muted on paper5.17AA
Paper on ink (button)14.70AA
Orange on paper (UI, large text)3.63AA large
Orange body text on paper5.24AA
Text on dark14.65AAA
Muted on dark6.55AA
Accent body text on dark5.37AA
Computed at build from design-tokens.css against opaque backgrounds · WCAG 2.1

View the design system

03 — Measurements

The home page ships 139KB of compressed JavaScript, which the browser expands to 467KB to parse. The measured bundle is Next.js runtime rather than application code. A small inline theme script is embedded in the HTML and excluded from these Resource Timing figures. Zero client components means nothing here adds a hydrated client island; it does not mean nothing is sent, because the App Router loads its client runtime whether a page uses it or not.

The figures come from scripts/measure-payload.mjs, which loads every route in the sitemap and reads the Resource Timing API rather than adding up chunk files, because that measures what a visitor actually downloads. The numbers are a budget as well as a record: the build fails if the payload grows more than five per cent past them.

Lighthouse scores accessibility 100 and best practices 100 against https://rsstdd.com/, identically in every one of 3 runs. Performance and SEO are not quoted, because they ranged 66 to 92 and 92 to 100 across those same runs. That spread measures how busy the machine running Lighthouse was rather than how quickly the site loads, and picking a number out of it would be publishing a property of a laptop. The figures above are deterministic, which is why they carry a budget and this does not.

JavaScript 139KB compressed, 467KB parsed · Largest route /blog/interview-question-bank at 320KB · 35 routes measured 2026-09-13 · Lighthouse 3 runs 2026-09-10, simulated mobile throttling, Lighthouse default preset

04 — Source

The repository is public. Fonts are self-hosted, and there are no third-party requests, so nothing about a visit is shared with anyone.

View the source