How I built billydavis.dev

This site started as a job-search portfolio and is evolving into a builder home base — projects up front, writing alongside, resume still available when someone needs the full picture.

Why keep it in the repo

I wanted something fast, cheap to host, and easy to change without a CMS. The content lives next to the code: project copy in lib/projects.ts, long-form resume in MDX, and now posts under content/writing/. Every publish is a git push and a Vercel rebuild. That is a feature at this scale, not a bug.

Stack choices

Next.js App Router handles routing, static generation, and metadata. Most pages are Server Components; client JavaScript is limited to things that need it (theme toggle, and an ElevenLabs widget that is currently disabled).

Tailwind CSS v4 with design tokens in globals.css keeps light and dark mode consistent without sprinkling raw colors through components. The typography plugin handles prose for MDX content.

MDX lets me write posts in Markdown with React components when needed. The resume page already used this pattern; writing posts follow the same approach.

Structure

• / — identity, featured projects, latest writing
• /projects and /projects/[slug] — proof of work with screenshots and outbound links
• /writing and /writing/[slug] — build logs and notes
• /resume — background when someone wants the career timeline

Nothing exotic: no database, no auth, no admin UI. Vercel Analytics for basic traffic.

What I would do differently next time

I would add the writing routes earlier so the site did not feel resume-first for as long. I might also generate the writing index from frontmatter in the MDX files instead of maintaining metadata in lib/writing.ts — but the explicit registry is simple and hard to break.

If you are building something similar, optimize for scan speed and verifiable proof (repos, demos, screenshots) before polishing hero copy. The design should get out of the way.