This site is my portfolio and my place to write. I also use it to develop ideas I can bring into Workhorse and client projects. I design the interface, organize the content, and work on the implementation.
The site has to accommodate people arriving for different reasons. Someone considering me for a role needs to find relevant work and experience. A potential client needs to understand what I do and how to get in touch. Other visitors come to read an article or explore a project.
A terminal for exploring the work
The terminal is an interactive part of the site. Visitors can ask questions about my experience or projects and follow links from the answers. It gives them another way to explore a portfolio that spans several kinds of work.
The ordinary navigation still matters. Work, About, and Contact have visible links, and the case studies can be read directly. Using the terminal is optional.
The terminal stays mounted as visitors move between pages, preserving the conversation. Its page context changes with the route. On application pages prepared for a particular role, the conversation can draw on that role’s context as well as the broader portfolio.
Keeping answers connected to the content
The chat retrieves passages from the site before generating a response. A build script indexes posts, application pages, the about letter, and the résumé. At request time, a text search finds relevant sections to include with the visitor’s question.
This gives the model material to work from and real pages to link to. It does not guarantee that every answer will be correct. The case studies and résumé remain the places to check the details.
Replies can include links or actions, such as opening a project or starting a contact request. The goal is to help someone take the next step from the conversation.
A shared structure for publishing
The site uses Astro with React for interactive components. Posts and case studies live in Markdown and MDX alongside the code. Their frontmatter provides titles, descriptions, images, and project details for the pages that display them.
That arrangement lets me revise the writing and presentation together. It also lets the homepage, work index, and individual case studies draw from the same project records.
Shared components and style tokens carry recurring elements across the site. The print layouts for résumés and application documents reuse parts of that system, with their own rules for pagination and typography.
Payload handles structured visitor submissions. The site runs on Cloudflare Pages, with D1 for production data and SQLite for local development.
Designing in the codebase
I use AI coding tools to help implement changes, investigate bugs, and work across files. I describe the behavior I want, review the proposed changes, and check the result in the browser.
The browser check is a necessary part of the work. A component can compile and still have the wrong spacing, lose state during navigation, or become difficult to use on a phone. Those are design problems I need to catch in the working interface.
When a pattern recurs, I move it into a shared component or helper. That reduces the number of places I need to change when revising the site.
What this project demonstrates
The site brings together content design, interface design, and implementation in a working portfolio. It includes conventional project pages, a conversational way to explore them, contact forms, and printable application materials.
It is also an ongoing project. I revise the structure and presentation as the work changes. The value of building it myself is being able to carry a design decision through to the behavior someone encounters on the page.
Related projects: Sacred Grove explores a similar development process in SwiftUI. The Aims of Education documents the extension of the print system into an essay edition.
