Personal

This Website: A Content-Driven Consulting Platform

I built my own site the way I'd build a client's product — content-driven, fully tested, accessible, and fast. Here's how I approached it, the decisions I made, and what that means for your project.

Role: Role: Product design, full-stack engineering & QA
Timeframe: Timeframe: 2026

View source

Overview

This website is my portfolio — but I treated it as a real product with a real goal: help potential clients quickly decide whether I'm the right person to build their software. That meant it couldn't just claim I deliver high-quality work; it had to demonstrate it.

So I designed and built it end to end as a production-grade application: content-driven, rigorously tested, accessible, fast, and easy to maintain. This case study walks through how I approached it and, more importantly, why — because the same thinking is what I'd bring to your project.

The brief I set myself

The objective was commercial, not decorative: turn visitors into conversations. A consulting site has to build trust in seconds, make it easy to explore proof of work, and remove friction from getting in touch.

It also had to be cheap to run, effortless to update, and able to grow — adding a new case study or service shouldn't mean paying for a rebuild.

What it had to achieve

Build trust and communicate value within the first few seconds
Present work as in-depth case studies, not just screenshots
Be fast, accessible, and discoverable by default
Be inexpensive to host and simple to maintain
Scale to new content without engineering work

Key decisions (and the trade-offs)

Static-first, with no database

Why:: The site pre-renders to static pages, so it loads almost instantly, costs next to nothing to host, and has no server or database to secure or maintain.
Alternatives considered:: A database-backed CMS would allow instant edits, but adds cost, complexity, a security surface, and slower pages — overkill for a site that changes when I choose to publish.

Separate content from design

Why:: All text and data live in a typed, validated content layer, kept completely separate from the visual components. Updates are quick and safe, and invalid content is caught automatically before it can ever go live.
Alternatives considered:: Hard-coding text into the design is faster on day one, but turns every future edit into a developer task and risks shipping broken pages.

Build quality in — testing and accessibility from the start

Why:: Automated tests and accessibility checks run on every change, so regressions are caught before release and the site works for everyone, on every device. Quality is proven, not promised.
Alternatives considered:: Leaving testing until 'later' is the industry default — and a big reason so many sites ship bugs and inaccessible experiences. Building it in costs a little upfront and saves far more downstream.

A reusable case-study platform

Why:: Case studies are assembled from typed content blocks, so adding a new project — or a whole new type of section — is a content task, not a redesign.
Alternatives considered:: Hand-designing each case study looks bespoke but doesn't scale; the site would need developer time every time the portfolio grows.

How it's built

Framework & language

Next.js
React
TypeScript

Design & UI

Tailwind CSS
shadcn/ui
Motion

Quality & delivery

Playwright
Vitest
axe-core
GitHub Actions
Vercel

A look under the hood

How content flows from typed, validated data to a fast, static site — tested and accessible at every step.
The same site in dark mode — theming built in from the start.

How I approached quality

Quality is where my background shows. Every change runs through automated formatting, linting, type-checking, unit tests, a production build, and end-to-end tests in a real browser — including an accessibility audit that must report zero issues. Nothing ships unless all of it passes.

This is the same discipline I bring to client work: catch problems early, keep the codebase healthy, and make it safe to move fast without breaking things.

The results

accessibility violations, checked automatically on every build: 0accessibility violations, checked automatically on every build
of pages statically rendered for speed: 100%of pages statically rendered for speed
automated quality gates before anything ships: 6automated quality gates before anything ships

What this means for you

If you're hiring someone to build software, this site is the proof: it's the standard I hold my own work to, and the standard I'd apply to yours — fast, accessible, tested, maintainable, and built to grow.

More than the specific technologies, it shows how I think: weighing trade-offs against your goals, building quality in rather than bolting it on, and making decisions that keep the long-term cost of ownership low.

This Website: A Content-Driven Consulting Platform

Overview

The brief I set myself

What it had to achieve