# Jay Weeldreyer — writing > Independent researcher and systems builder who finds the actual problem inside underdefined situations and turns it into experiments, products, operating systems, and decisions. --- ## Why this site is strange Essay · Working note · 2026-06-27 Source: https://jayweeldreyer.com/writing/why-this-site-is-strange > The site is not only a personal website. It is also an experiment in making delegated LLM work operational through public, inspectable structure. This site is a little strange on purpose. It is a personal site in the ordinary sense: a public home for work, writing, contact, and current movement. But that is not the whole object. It is also an experiment in a newer pattern: making a public artifact that can be read by people and operated against by language models working on their behalf. That does not mean treating LLMs as independent actors with their own purposes. The useful frame is more grounded than that. LLMs are increasingly delegated operators: systems people use to read, compare, summarize, route, draft, test, and move work across contexts. They do not need a mystical theory of agency to matter. They already change the shape of what a useful interface can be. Most of the internet was designed for human attention. Pages assume eyes, scrolling, navigation, visual hierarchy, persuasion, forms, and clicks. That is still real. But models use the web differently. They work from documents, schemas, examples, logs, file structures, instructions, and routes. They can read a page, but they can also use a plain-text corpus, inspect a manifest, follow a protocol, compare claims against records, and carry structured context into the next action. That makes a website something more interesting than a brochure. ## From content to capability The immediate purpose of this site is simple: help people and the LLMs working for them determine whether there is a reason to connect, and make useful public material easy to collect when there is not. But the deeper experiment is about capability. Some model-facing artifacts are not merely content, prompts, or documentation. They are scaffolds: external structures that let a model exercise a capability more reliably than it could from a bare prompt. The model supplies flexible interpretation, synthesis, and adaptation. The scaffold supplies names, boundaries, procedures, checks, memory, and records. Neither side is sufficient by itself. The capability appears in the coupling between them. That is the pattern I am interested in: **latent model capability + external scaffold + validation loop = usable operational capability** The scaffold does not replace the model. It also does not merely tell the model what to do. It gives the model a structured world to work inside: objects it can name, paths it can follow, constraints it must respect, and records that make the work inspectable after the fact. ## Better metrics, or new functions Much of the current conversation about LLMs is about doing familiar work faster: more copy, quicker summaries, cheaper analysis, faster code, better support throughput. That category matters. Better metrics on existing functions are real. But it is not the whole opportunity. The more interesting category is work that could not be done, or could not be done at useful scale, without LLMs. Not because the task was impossible in principle, but because it required too much context transfer, too much translation between domains, too much conversational narrowing, or too much custom integration for each situation. Discovery is one of the places this becomes visible. Individuals, organizations, projects, systems, funders, customers, collaborators, and tools often fail to find each other even when there is strong latent fit. The public internet made people and organizations searchable, but search is still a thin instrument. It retrieves pages. It does not always understand situations, infer fit, compare needs to capabilities, prepare context, or lower the cost of a first useful exchange. LLMs change that surface. A person can delegate exploration. A model can read across public artifacts, assemble context, test possible fit, prepare an introduction, and carry forward the relevant state. That does not make the model the source of judgment. It does make new interaction patterns possible. This is the architecture I am probing: - humans with real situations, constraints, needs, and judgment; - LLMs acting as delegated operators across documents and systems; - public artifacts structured for models to fetch, inspect, and use; - durable records that make the interaction accountable after the fact. The site is an early version of a tool for that architecture. It is trying to be legible as a human profile, a machine-readable corpus, a capability manifest, an audit trail, and a routing surface at the same time. That combination points toward a larger unlock: enhanced search, discovery, onboarding, integration, and collaboration. Not merely "find a page," but "find whether there is a reason to connect, what each side should know before connecting, what can be reused without connecting, and what useful action should happen next." If that works, the website is not just a destination. It is part of the coordination layer. ## What the site already does This site is a modest instance of that pattern. The source of truth is a git repository. Content lives in typed collections. Pages are generated from source files. Writing, work, and daily log entries have plain-Markdown mirrors. `/llms.txt` indexes the site for language models. `/llms-full.txt` exposes the writing corpus as a single plain-text document. `/capabilities.txt` and `/capabilities.json` describe the current public capability surface. The Done log records recent movement, so the site is not only making claims about itself; it is leaving receipts. None of that is advanced software in the usual sense. That is part of the point. The first useful version of this pattern does not need a complex runtime. It needs durable public structure. A model can fetch the corpus, inspect the capability manifest, read the work history, check the recent log, and prepare a more specific introduction than a human would usually write from a cold browse. It can also decide there is no fit and still extract language, distinctions, or examples that are useful elsewhere. That is already a different interface pattern from "look at my homepage." ## Operationalizing functional delegation The phrase I keep circling is **functional delegation**. Not delegation as vague automation. Not delegation as pretending the model owns the goal. Functional delegation means a person can hand a model a real task and a structured environment in which the task can be performed with less ambiguity, more continuity, and better evidence. That environment might include: - a knowledge substrate; - an operational grammar; - typed objects or states; - routing rules; - constraints and gates; - examples of acceptable work; - tests or checks; - durable witness records; - a lifecycle for revision. In ordinary software, many of those things are hidden inside code. In LLM-facing work, many of them can be expressed directly as text, files, directories, schemas, and generated public artifacts. That is strange only because the web trained us to think of sites primarily as things people look at. For delegated model work, a site can also be a thing a model _uses_. The important question is not whether the page looks interactive. The important question is whether the structure enables better action. Can a model understand what the artifact is for? Can it find the current capabilities? Can it distinguish stable claims from provisional notes? Can it retrieve source-like text instead of scraping presentation? Can it route a situation toward contact, reuse, or dismissal? Can a person inspect what the model relied on afterward? Those are interface questions. They are also governance questions. ## Why public matters There is a private version of this pattern: local folders, working notes, prompts, scripts, logs, and tools used with a model in a private environment. That is useful. But public structure changes the affordance. When the scaffold is public, it becomes addressable. A person can send a model to it. Another model can fetch it. A future system can compare against it. The artifact can be linked, cached, tested, versioned, and criticized. It can become part of a wider network of delegated work without requiring a private handoff first. That does not make every public artifact important. Most will not be. The point is narrower: if LLMs increasingly work through documents and structures, then public documents and structures can become operational surfaces, not just publication surfaces. The website is the visible edge. The repository is the canonical object. The generated artifacts are the machine-facing surface. The human pages are still real, but they are no longer the only interface. ## The constraint The constraint is utility. It would be easy to make this grander than it deserves to be. A capability surface that does not help anyone do anything is just decorative machinery. The site has to earn its strangeness by making connection, evaluation, reuse, or learning easier than it would otherwise be. So the current version is intentionally small. It exposes a few routes. It makes the corpus fetchable. It names the capability surface. It keeps a log. It lets the structure evolve under version control. That is enough to begin. The direction is broader: public configurations, reusable procedures, evaluation rubrics, promptable workflows, task routers, research packets, and small web-addressable artifacts that help models do useful work without a person reconstructing the method from scratch every time. Some of those will turn out to be valuable. Some will not. The site is a place to find out in public. ## Why this site is strange This site is strange because it is not only a representation of work. It is part of the work. It is an output of AI-assisted building, writing, and revision. It is also an evolving instantiation of the pattern being explored: external structure that makes delegated model work more reliable, inspectable, and useful. That may become a dead end. It may become ordinary. It may become one small instance of a much larger design pattern that eventually gets better names. For now, the claim is simpler: A website can be built for human readers and delegated model operators at the same time. It can publish ideas, but it can also publish structure. And when the structure is useful enough, the site stops being only a place where work is described. It becomes one of the places where work can happen. --- ## A site that explains itself Essay · Revised · 2026-06-25 Source: https://jayweeldreyer.com/writing/a-site-that-explains-itself > Why this site is, for now, mostly about itself — and what that choice says about how it is made. A site with no writing on it yet has two honest options. It can fill the empty space with placeholder — lorem ipsum, or a sample post that announces it is a sample post — and ask the reader to imagine what will eventually be here. Or it can describe itself: treat its own construction as the first thing worth writing down. This site takes the second option. Until there are real essays, the writing is about the site. That is not a stall. It is a small statement about the kind of object the site intends to be. ## The shape of the thing The organizing idea is separation. What the site _says_ and how the site _looks_ are kept in different places, on purpose. The words live in plain text files — Markdown, mostly, the kind of thing you can read in a terminal. The look lives in a small set of design tokens: named values for color, type, spacing, and rhythm. Neither knows much about the other. You can rewrite every sentence without touching the design, and re-theme the entire site — the dark surface you are reading on, or its light inverse — by changing a handful of tokens, without touching a sentence. This is not a clever trick; it is just good hygiene, the same instinct that keeps a model legible by keeping its parts loosely coupled. But it has a pleasant consequence. The content can evolve as fast as thought, because changing it never risks the structure. > A personal site is a place to think in public. Its machinery should be quiet enough that you forget it is there. > > — The shape of the thing ## Quiet machinery The second principle is restraint. The site is static: every page is built ahead of time into plain HTML and served as-is, with almost no JavaScript along for the ride.[^1] There is a theme toggle and a thin reading-progress bar; that is nearly the whole of it. Nothing here needs to phone home, hydrate, or re-render in your browser to show you a paragraph of text. The payoff is durability. A page that is just HTML and a stylesheet will still open in ten years, will load instantly on a bad connection, and can be read by a machine as easily as a person. For a site whose job is to hold writing, that is the right set of trade-offs — fast, legible, and boring in the way that infrastructure should be boring. ## Why describe itself at all The self-describing premise is the part that could read as indulgent, so it is worth being plain about. The point is not to admire the construction. It is that a site documenting its own making is being honest about its current state instead of hiding it — and honesty about state is the same discipline this site is otherwise about. A taxonomy that refuses to name its remainder is lying about what it is doing; a site that papers over its emptiness is doing a smaller version of the same thing. So the writing you will find here, for now, is a true account of one object: how it is built, how it is changed, and the few decisions that gave it its character. Each piece is also a demonstration — this one is an essay, with its metadata in the rail and its notes at the foot; the next is a technical note, with figures and code. The form is part of the message. When there is real writing to do, these pieces step aside, one at a time. The site will stop being about itself and start being about the work. Until then, it is exactly what it appears to be, and says so.[^2] [^1]: The site is built with Astro and deployed as static files. The mechanics are the subject of the next piece, _How this site is built_. [^2]: It was also assembled with a good deal of AI assistance — which, for a site partly about AI-enabled reasoning, seems less like a disclaimer than a fitting detail. --- ## Reality-coupled action Operating memo · Working note · 2026-06-25 Source: https://jayweeldreyer.com/writing/reality-coupled-action > Why this site is a living artifact rather than a brochure — and the premise underneath the way I work. This site is a living artifact, not a brochure. What's here is the current state of how I work and think — and it is meant to change. Nothing on it is placeholder waiting for the "real" version; this _is_ the real version, as of now. ## Agent-native It's built and evolved with AI agents as first-class collaborators, in tight loops: edit, see it, publish. The structure underneath is shaped to make that safe and legible rather than loose — content that's checked against a schema before it can ship, and a public log that keeps an audit trail of what actually changed. "Agent-native" isn't a posture here; it's a structure, and it's checkable. It isn't built this way once and left alone, either — it's actively kept current by LLMs working under my direction. The byline on each piece says who did which part: the editorial judgment is mine; the drafting is often theirs. ## A current state, not a placeholder The content is real and provisional at the same time. It's the present reading on a coupling surface — one contact patch, of potentially many, where the work meets reality and coordinates with other people. A better version replacing this one is the point, not a failure of this one. ## Two readers It's written for two audiences at once: people, and the language models that increasingly read and act on their behalf — so it tries to stay legible and discoverable to both. And the form isn't fixed. Today it's a surface you read; in some configurations it could become one you act _through_ — an interface other systems operate against rather than a page they parse, even, eventually, a compute surface for them. Which of those it becomes is open. Keeping it a current state, rather than a finished thing, is what leaves that door open. > State the principle once, then show it in the work. A manifesto reads as the absence of receipts. > > — Reality-coupled action ## It embodies what it's about The site runs on its own thesis: reality-coupled action. Claims carry receipts. Verifiability is worth more than effort or assertion. The [Done](/done) log is me pointing that same instrument at myself. ## The premise underneath The made world — institutions, markets, money, organizations — is synthetic: authored, and therefore editable. We are unavoidably its co-creators. The only real choice is whether we do that on purpose or by default — by mistaking the artifact for nature, treating something we built as if it were a law we found. The work, everywhere, is the same shape: couple action to reality, separate the natural constraints from the man-made ones, reconnect consequence to its cause where that loop has been cut, and aim at the highest-leverage thing within reach. This will be refined too. That isn't a disclaimer — it's the method. --- ## How this site is built Technical note · Revised · 2026-06-24 Source: https://jayweeldreyer.com/writing/how-this-site-is-built > A flexible, agent-managed operating surface — and the transferable pattern underneath it: author once, derive every machine-readable surface, guard the invariants. Read this two ways at once. On the surface it is a description of one small website — its files, its routes, the host it sits on. Underneath it is a worked example of a general pattern, and the pattern is the part worth keeping. So each section names the specific thing _and_ the transferable rule it stands for. Strip out the name and the particular work, and what remains should still be buildable by anyone. The terminology is now separated more precisely. [Public Interface](/public-interface/) defines the durable contract and its trust boundary. The [architecture record](/architecture/) reports what this production instance actually implements and how it performs. This note explains the engineering reasoning between them. The thing to resist is the obvious framing. This is not a brochure, and it is not even mainly "a publishing system." > It is a flexible public operating surface: built to evolve quickly under agent management, while keeping its source legible, its outputs derived, its claims auditable, and its maintenance surface small. Everything below is downstream of that one sentence. The stack is not a set of taste preferences; it is a set of answers to the question _how do you make a surface that can change fast without becoming fragile or dishonest._ ## §1 What this is A single durable surface that several different jobs run through. Concretely, for this site, the jobs are these — and they are roughly the jobs any person, company, or project eventually needs a public surface to do: **Explain.** Let a human or an agent understand who this is, what the work is, and how to engage. **Publish.** Hold essays, notes, technical memos, and operating artifacts — durably, at stable URLs. **Evidence.** Show work, decisions, and change over time, with receipts. The Done log is this function. **Coordinate.** Make contact, collaboration, and context-transfer easy, for people and for their tools. **Represent.** Give humans and language models a current, structured model of the person and the work. **Adapt.** Let the surface change quickly as the work changes, without each change risking the whole. **Operate.** Support agent-managed updates, QC passes, derived artifacts, and future workflows. The site is the current expression of that list, not the final one. New functions get added the same way everything else did — as content and small derivations, not as a rebuild. ## §2 Functional objectives Before any tool, the requirements. A surface like this has to: 1. Make the authored material — the writing, the work history, the receipts — the single source of truth. 2. Be readable by both humans and machines from that one source, with no separate "API" to keep in step. 3. Be fast and durable: no runtime to fall over, nothing to patch at 2 a.m. 4. Change quickly and safely, so an edit is cheap and a bad edit is caught before it ships. 5. Keep its claims honest — what it says is done should be backed by something a reader can check. Every concrete choice that follows is there to satisfy one of those five. When a choice doesn't trace back to one of them, it's decoration, and it gets cut. ## §3 The pattern The architecture, with the specifics removed, is a short pipeline. Content is authored once, in a typed schema; everything else is _derived_ from it at build time; the result is static and validated before it goes out; and the live surface is checked on a schedule to close the loop with reality. *Listing 1 — the pattern, with the specifics removed.* ```text authored content (typed, human-written, the only source of truth) │ ▼ build / derive ├─ rendered pages ├─ sitemap + feeds ├─ machine-readable surfaces (index, plaintext, structured data) └─ indexes (e.g. an activity log) │ ▼ static deploy (no server, no database) │ ▼ build-time guards (no deploy without passing invariants) │ ▼ live QC on a schedule (does reality still match the build?) ``` That is the whole idea. The rest of this note is just one honest instance of it, so the abstraction has something to stand on. ## §4 This implementation The specific tools that fill in the pattern: **Astro, static output.** The framework. Every route is pre-rendered to HTML at build time; there is no server runtime and no database. It ships almost no JavaScript by default, which is the whole reason to use it for a content surface. **TypeScript + MDX.** Strict TypeScript throughout. Plain Markdown for prose; MDX only where a piece needs components — figures, captioned code, definition lists. **Content collections (Zod-typed).** Writing, work, static pages, and the Done log are each a typed collection with a schema. Front-matter that violates the schema fails the build instead of shipping broken. This is the "single source of truth, typed" leg of the pattern. **CSS design tokens.** Semantic CSS custom properties — colour, type, spacing — are the single source of truth for look. Components reference tokens, never raw values, so one change propagates everywhere. Dark is the default; light is the same tokens, inverted. **Self-hosted fonts.** Source Serif 4, Public Sans, and JetBrains Mono, bundled locally. No third-party font CDN, so there is no external origin to allow. **GitHub + Cloudflare Pages.** The Git repository is the source of truth; Cloudflare Pages builds it and serves the result from its edge. Package manager pnpm, Node 22. A collection is a folder of Markdown plus a schema. The schema earns its keep: every entry is checked against a declared shape before it can build, which is what makes editing safe and keeps a stray field from slipping through. *Listing 2 — a content collection (abridged).* ```ts const writing = defineCollection({ loader: glob({ pattern: "**/*.{md,mdx}", base: "./src/content/writing" }), schema: z.object({ title: z.string(), description: z.string(), date: z.coerce.date(), type: z.enum(["Essay", "Note", "Technical note", "Operating memo", "Case fragment"]), tags: z.array(z.string()).default([]), draft: z.boolean().default(false), }), }); ``` A piece's `type` selects its reading layout; `draft: true` removes it from the build, the listings, and the feeds. The whole pipeline is small enough to hold in your head: > **Figure 1.** The instance of the pattern: content and design tokens are read at build time into static HTML, served from the edge. The only runtime is the reader's browser. A push to `main` triggers a build on Cloudflare Pages, which runs the same command anyone can run locally and publishes the output to a global edge network. Pull requests get their own preview deployments. There is nothing to roll back beyond reverting a commit. ## §5 What is derived This is the leg most sites skip, and the one that makes the surface multi-purpose. Everything machine-facing is _generated from the collections at build time_, never maintained by hand: - **`/llms.txt` and `/llms-full.txt`** — an index of every piece, and the writing concatenated as one Markdown document, for language models. - **Markdown mirrors** — append `.md` to any writing, work, or Done URL to get the plain source the page was built from, with no HTML to parse. - **JSON-LD** — Schema.org `Person`, `WebSite`, `ProfilePage`, `BreadcrumbList`, and `Article` data, emitted from the same canonical data that renders the pages. - **Feeds and sitemap** — RSS for the writing and for the Done log, plus a sitemap, all from the same source. The mechanism is dull on purpose: a route reads the collection and emits text. *Listing 3 — a derived surface (the Markdown mirror, abridged).* ```ts // One Markdown file per entry, from the same collection the page is built from. export const getStaticPaths = async () => { const entries = await getCollection("writing", (e) => !e.data.draft); return entries.map((entry) => ({ params: { slug: entry.id }, props: { entry } })); }; export const GET = ({ props }) => new Response(toMarkdown(props.entry), { headers: { "Content-Type": "text/markdown; charset=utf-8" }, }); ``` Because these are derived, adding one piece of content updates all of them at once. The transferable rule: _the source is authored; every other surface is computed._ ## §6 What is guarded Derived artifacts can't drift from the content — but the _generators_ can be wrong, stale, or under-specified. So the maintenance burden doesn't vanish; it moves from "remember to update seven files" to "keep one small compiler honest." That is a huge win, and it is enforced by a short list of invariants the build will not break: - **No maintained sidecar files** — if it's machine-readable, it's generated. - **No runtime unless genuinely necessary** — static by default. - **No deploy without passing build checks** — the gate is the build. - **No machine-readable surface detached from its source content.** - **No claim of "done" without a receipt.** These are not aspirations; they run on every build, and Cloudflare runs the same line, so a violation can't deploy: *Listing 4 — the build gate (package.json).* ```json "build": "astro check && astro build && pnpm guard:css && pnpm guard:artifacts" ``` `astro check` type-checks; `astro build` renders to `dist/`; `guard:css` fails the build if an inline `style` attribute slips into the output (it would be blocked in production by the hashed Content-Security-Policy); `guard:artifacts` fails the build if a generated artifact is missing, an entry lacks its Markdown mirror or its `llms.txt` line, an internal link is broken, or any JSON-LD block won't parse. A separate weekly job runs **live QC** against the deployed site — pages resolve, the sitemap is honest, the machine-readable layer is reachable, a missing path still 404s — and opens an issue if reality has drifted from the build. The security surface is small for the same reason the rest is: nothing runs at request time. Astro generates a strict CSP at build, hashing the few inline scripts and styles it controls, with no `'unsafe-inline'`; a short `_headers` file sets the rest (HSTS, `X-Frame-Options`, and so on); fonts are self-hosted; there is no server or database to harden. ## §7 What this avoids Each invariant exists to head off a specific, common failure: - **Sidecar drift** — a hand-kept `llms.txt` or feed that slowly stops matching the site. (Killed by: generate everything.) - **Integration debt** — every third-party widget and runtime is a thing that breaks later. (Killed by: static by default.) - **A CMS you now have to operate** — the database becomes the project. (Killed by: content is files in Git.) - **A frontend that buries the content** — motion and cleverness over legibility. (Killed by: tokens and almost no JavaScript.) - **Generated artifacts rotting silently** — the worst kind, because it looks fine. (Killed by: the artifact guard and live QC.) - **"Aboutness" replacing receipts** — claiming impact with nothing to check. (Killed by: the Done log and the no-claim-without-receipt rule.) ## §8 How to copy it Strip out the specifics and the recipe is short: 1. `pnpm create astro@latest` — minimal template, strict TypeScript. 2. Add MDX, sitemap, and RSS. 3. Define content collections with typed schemas; keep all prose as files in the repo. 4. Put every visual decision in CSS custom properties; build a small set of primitives that read only those tokens. 5. Add routes that _derive_ machine-readable surfaces — an index, plaintext mirrors, structured data, feeds — from the collections. 6. Make the build the gate: type-check, render, and run guards that assert your invariants. Self-host fonts; turn on a hashed CSP. 7. Push to a static host that builds on commit and previews on PR. Add a scheduled live-QC check against the deployed surface. That is the entire pattern. Everything in it is in service of one property: content enters once, and the system does the rest — every time, without adding a chore. ## §9 Why this matters The architecture is the thesis in miniature. A surface where the source is authored, the outputs are derived, the invariants are enforced, and the live state is checked is just [reality-coupled action](/writing/reality-coupled-action) applied to a website: keep the claims, the artifacts, and reality coupled, so the thing can change fast and stay honest at the same time. The specific site is the example. The general system is the public read layer of a Public Interface: small, durable, agent-maintainable, and explicit about what it does not authorize. The [public reference implementation](https://github.com/submit77/public-interface) contains that reusable pattern without the personal content or private production history. --- ## The content workflow Operating memo · Working note · 2026-06-23 Source: https://jayweeldreyer.com/writing/the-content-workflow > How words get from a thought into the live site — the edit, preview, and publish loop, and the rule that keeps it honest. A site that is painful to change does not get changed. So the workflow matters as much as the architecture; it is the part you actually live in. The aim here was a loop short enough that editing a sentence feels like editing a document, not deploying software. It works like this. The content lives in plain files. A local preview runs on the machine and watches those files; saving a change updates the open page in about a second. When a batch of changes looks right, a single step publishes them, and the live site rebuilds within a minute or two. Edit, watch, publish — that is the whole of it. ## The repository is the source of truth One rule holds the workflow together: the repository is canonical. Not a database, not a content-management dashboard, not a design tool — the versioned files are the site. What builds from them, passes its checks, and deploys is what ships, and nothing else. The discipline this buys is worth more than it costs. Every change is a commit, which means every change is reversible, attributable, and visible. There is no drift between a pretty editing surface and the real thing, because there is only one thing. If a design tool or an assistant proposes a change, the change is real only once it lands in the repository. ## Markdown by default, MDX when needed Most writing is plain Markdown, because plain Markdown is the most durable way to store prose — it is legible on its own and will outlast any particular tool. The richer machinery — figures, diagrams, captioned code, definition lists — is available, but only for the pieces that genuinely need it, and only by opting in. The default is the simplest thing that works. This is the same instinct that runs through the rest of the site: keep the common case boring, and reserve complexity for where it earns its place. A note should be a note. A technical piece can be more, when there is something to show. ## Why not a CMS A content-management system would add an editing interface and, with it, a server, an account model, and a second source of truth to keep in sync. For a site whose content is a folder of text files, that is a great deal of apparatus to manage a small amount of writing. The repository already does the job — version history, review, rollback — and does it without anything to maintain. If the day comes that editing in files genuinely chafes, a CMS can be added on top of the same files. Until then, the files are the system. --- ## Dark by default Note · Note · 2026-06-22 Source: https://jayweeldreyer.com/writing/dark-by-default > A short note on why the site opens dark, and what the choice is meant to signal. Most sites open white because white is the default of the medium — paper, then the screen that imitated it. This one opens on a warm near-black instead, and offers a light version only to those who go looking for it. The choice is small but not arbitrary. A reading surface is not a sheet of paper. Held at arm's length on a lit screen, a dark page is calmer to sit with, and it pushes the text forward instead of the background. The palette here is warm rather than clinical — a near-black with a little brown in it, off-white type, a single restrained terracotta for emphasis — so the effect is closer to ink on a dark cloth than to a terminal. There is a second reason, more about stance than comfort. A default is a position. Opening dark says, quietly, that this is a place for reading rather than for scanning a feed; that the surface is chosen, not inherited. The light theme is there for daylight and for preference, and it costs nothing — the same tokens, the same site, inverted. But the door opens onto the dark, on purpose. --- ## From prototype to production Case fragment · Note · 2026-06-21 Source: https://jayweeldreyer.com/writing/from-prototype-to-production > A short retrospective on converting the original browser-rendered mockup into a static, production site. The site began as a prototype that ran entirely in the browser. It pulled React, a rendering library, and a compiler down from a public CDN, then assembled itself from a set of component files at page load. As a way to see the design quickly, this was fine. As a way to ship, it was wrong in every respect that matters: it shipped a compiler to every visitor, depended on third-party origins to render a paragraph of text, and produced nothing a search engine or a reader without JavaScript could see. The conversion kept the design and discarded the delivery. The visual direction survived intact — the warm near-black palette, the three typefaces, the editorial layout — because that work was good and worth preserving. What changed was everything underneath it. The component logic was rebuilt to run at build time instead of in the browser. The content, which had been hard-coded inside the components, was lifted out into typed Markdown. The runtime libraries and the CDN were removed entirely. What came out the other side is ordinary static HTML: pre-rendered pages, a strict content-security-policy that the old setup could never have satisfied, self-hosted fonts, and almost no JavaScript. The page you are reading is the same design the prototype showed — only now it is a finished object rather than a set of instructions for assembling one in your browser. The general lesson is the dull one that keeps being true: a mockup and a product are different kinds of thing, and the move between them is mostly a matter of deciding what runs when. The prototype did its work by deferring everything to the browser. The product does its work by having already done it.