Colophon

How this site is built.

This site is part portfolio, part publishing system, part AI interface, and part working artifact.

The repo is the product surface. WordPress is where it renders.

I write projects, essays, and pages in Markdown with YAML front matter, then publish them through a Python script using the WordPress REST API. The theme lives in git and is deployed from source. Claude Code is part of the workflow for drafting, theme iteration, front-end refinement, and server operations.

That is the same compression I describe in client work: faster iteration, tighter feedback loops, and human-owned decisions.

The site is not just a place where finished work is posted. It is part of the practice: a live system for publishing, testing, explaining, and extending the work as it evolves. The design kit renders live against production CSS.

A conversational interface for exploring the work.

It started from a simple problem: portfolios are usually organized around the designer’s structure, while visitors arrive with their own questions. A recruiter may want a fast read on role fit. A hiring manager may want evidence of process, systems thinking, or AI product experience. A collaborator may want to understand how something was built. A static portfolio asks all of them to browse the same way.

PAI gives them another path through the work.

The interface is built around the idea that the conversation is the navigation. Visitors can ask a question in plain language, and PAI retrieves relevant material from a structured corpus of case studies, project notes, methodology writing, professional background, podcast material, and live site content. It answers from that grounded knowledge, then opens supporting work in a sidebar when the answer needs evidence.

The architecture is deliberately product-shaped, not demo-shaped. A React/Vite frontend sends requests to a Node/Express backend running on AWS Lightsail. The backend handles retrieval, prompt assembly, provider routing, streaming responses, tool dispatch, and voice services. The main conversation streams over server-sent events, keeping the interaction fast without adding unnecessary WebSocket complexity.

The corpus is the product layer that matters most. PAI uses roughly 3,900 structured chunks, explicit keyword scoring, intent detection, source weighting, and pinned “always include” context for core facts like positioning and availability. It also supports live annotations, so corrections or curator notes can be added without rebuilding the corpus or restarting the server.

The panel system is the key interaction design decision. PAI does not just talk about portfolio work; it can open it. When the model identifies a relevant case study, post, access request, or generated explanation, it dispatches a tool call that loads the right content into a persistent sidebar. WordPress pages are proxied, stripped of site chrome, and served as same-origin panel content so the conversation and the evidence stay connected.

Voice is part of the interface, too. Speech-to-text runs through Deepgram via a server-side proxy, while text-to-speech can route through multiple providers. Spoken responses are normalized before playback, with markdown removed, acronyms handled, URLs made speakable, and pacing calibrated so the result sounds closer to conversation than text-to-speech output.

PAI is both a portfolio feature and a product design experiment. It asks what happens when a portfolio becomes a queryable knowledge system: part guide, part search layer, part recruiter assistant, part case study interpreter.

The point is not that the site has AI on it.

The point is that the AI has a job: help visitors get to the right evidence faster, at the depth they need, in the moment they need it.

AI all the way down, except the thinking.

Episodes are scripted from my notes, case work, and research, then produced with AI-generated hosts. The curation, argument, and editorial judgment are mine. The voices and production are synthetic.

It is a deliberate experiment in how far AI tooling can stretch a solo product practice: turning research, reflection, and project notes into something more durable than a notebook and more conversational than an essay.

The podcast is not meant to replace writing. It is another format for thinking in public.

This page is for build notes that matter: a constraint that changed the layout, a publishing quirk worth remembering, a workflow that actually held.

Not a changelog.

When the meta is worth keeping, it lands here.

All illustrations on this site are created by hand. I sketch on paper first — usually pen on whatever’s closest — then refine digitally on iPad in Procreate. The same hand that draws the wireframes draws the storyboards — thinking through problems before pixels.

The artwork, mockups, high-fidelity prototypes, videos, and marketing collateral across the case studies are also my work — designed and produced as part of each engagement.

Storyboard sketch in Procreate on iPad

Storyboard sketch — Procreate on iPad

A feedback loop is a self-regulating cycle: output circles back as input, and each pass adjusts what happens next. In UX, it is the continuous exchange between a person and a system. Every action generates a response. Every response shapes the next action.

That is how products learn.

A loupe is a small lens for examining what is easy to miss. Jewelers use them. Watchmakers use them. Anyone whose work depends on seeing the detail that changes the decision.

Feedback Loupe is a conceptual portmanteau: the loop that keeps running and the lens held up to what it surfaces.

Build, ship, watch what happens, look closer, adjust. The process is continuous. The inspection is deliberate.

Stack

WordPress 6.9 · AWS Lightsail · Apache · Debian 12 · Twenty Twenty-Five child theme · Fraunces + Source Sans 3

Workflow

Markdown + YAML → Python publish script → WordPress REST API · Theme in git, deployed via rsync · Claude Code throughout