Project Overview
This is the site you're reading this on. It has three jobs: show finished work, tell the story behind that work in enough depth to be useful to someone else, and make it obvious there's a real person — not just a brand — behind both.
The Idea
I kept running into portfolios that either showed polished project thumbnails with no explanation of the thinking behind them, or long-form build logs with no clear place to see the finished work first. I wanted both, without either one diluting the other — a visitor skimming for finished work shouldn't have to wade through process notes, and someone who wants the full story shouldn't get a thin summary that's really just a gallery caption.
Planning
Before any layout work, I wrote down the identity in one sentence: a designer-engineer's terminal-meets-canvas, monospace headlines on a cool graphite surface, one electric-blue accent, reserved strictly for interactive elements. Everything downstream — color usage, card styles, motion — had to serve that sentence or get cut.
I also decided early that Projects and DaveBuilds needed to be structurally separate, not just visually distinct sections on the same page: every finished project gets exactly one dedicated DaveBuilds page, linked in both directions, so neither section can quietly become a dumping ground for the other.
Design
The two identities got two different card languages on purpose. Project cards look like code-editor windows — traffic-light dots, a tab header — because they represent shipped software. DaveBuilds cards are glass panels with a category tag and an excerpt, because they represent writing, not software. Same design tokens, deliberately different silhouette.
The DaveBuilds article pages went through one significant revision: the first pass had no table of contents, and on a nine-section page that made it hard to jump straight to, say, "Challenges." Adding a sticky table of contents with scroll-position highlighting fixed that without adding any real visual weight to the page.
Development
The original site used vanilla HTML, CSS, and JavaScript — no framework or build step. Project
and story data live in one shared data.js array so the Projects grid and the
DaveBuilds landing page can never drift out of sync with each other; shared page behavior
(theme toggle, mobile menu, scroll reveal) lives in common.js so it's written once
and reused across every page.
The reading progress bar on story pages is pure CSS — no scroll listener at all:
.scroll-progress {
position: fixed; inset: 0 0 auto 0; height: 3px;
background: var(--portfolio-color-primary);
transform-origin: 0 50%; transform: scaleX(0);
animation: progress linear both;
animation-timeline: scroll(root block);
}
@keyframes progress { to { transform: scaleX(1); } }Challenges
The nav needed to work identically whether you were already on the homepage or arriving from
a story page three links deep. The shared navigation uses index.html#projects as the href everywhere, including on the homepage
itself — browsers treat a same-document hash link as a plain in-page jump, so one nav
markup works correctly on every page with zero conditional logic.
Keeping the table of contents usable on mobile was the other real challenge: a sticky sidebar simply has nowhere to go on a narrow screen. It collapses into a toggle button that expands the same link list inline, so there's exactly one TOC markup block per page instead of a separate mobile version to keep in sync.
Final Outcome
The site shipped as a small set of static HTML pages: a homepage, a DaveBuilds landing page,
and one story page per finished project — including this one. In that version, adding a finished project
meant one entry in data.js plus one copy of the story template, and both
the Projects grid and the DaveBuilds grid update themselves.
Reflections
Deciding the Projects/DaveBuilds split before writing any markup is the single decision I'm most glad I made early — every layout question after that had an obvious answer, because it was really a question of which identity a piece of content belonged to.
If I revisit this later, the thing I'd change is moving story content out of static HTML and into a small content file per project, so writing a new DaveBuilds page means writing prose, not editing a page's markup directly. For a two-project portfolio it wasn't worth the extra layer yet.