How this site is built

This site has one job: show what I have built, clearly, without overstating any of it. These are the decisions behind it.

The design

The direction is deliberately quiet. Light surfaces, one accent colour, large type, and a lot of space. Motion is slow and it always means something: a headline arriving, a paragraph you read as you scroll, a project visual that changes state as its story advances. Nothing loops for decoration, and everything stands still if your system asks for reduced motion.

Each featured project gets a chapter rather than a card. The visual pins in place while three short captions move past it, so you see the idea, then what is built, then what is still open.

The visuals are coded, not captured

The project visuals on the home page are components, drawn in HTML, CSS, and SVG. They are illustrations of how each system works, and they are labelled as illustrations. Where a product is not public yet, a drawing that explains the idea is more honest than a screenshot that implies a launch.

The one content rule

Every case study separates what exists from what is planned, in two lists that never mix. If a model benchmark did not meet its acceptance criteria, the page says so. If a project is a concept, it is called a concept.

I also say how the work gets made. I design systems, write the specifications, and direct AI coding agents through implementation, while keeping architecture, testing requirements, and release decisions for myself. This site was built the same way, from a written plan.

The stack

• Next.js with the App Router, statically prerendered.
• React view transitions for the morph between a project chapter and its case study.
• Tailwind CSS with a small set of design tokens, so the dark theme is the same components with different values.
• Motion for scroll-linked animation.
• MDX for notes like this one.

There is no database, no tracking, and no contact form. If you want to reach me, the links are at the bottom of every page.