How this portfolio is built, and what it's built to prove

A portfolio is the one project where the audience is already inspecting the work while reading about it. Every other case study on this site asks you to take my word for a screenshot. This one doesn't get that luxury — you're standing inside the artifact as you judge it.

That changes what the site has to do. It can't just list projects and credentials. It has to operate as proof of how I think, build, and make decisions — for two audiences reading it for different reasons, at the same time.

If the case studies are the evidence, the site holding them is the closing argument.

Two readers land here with different questions. Engineers and hiring managers ask "can this person build something maintainable, fast, and considered?" — and they'll check by reading the code-quality signals: how the type system is used, how the build is structured, whether the animation is hand-rolled or bolted on. Clients evaluating a redesign or a new build ask "will working with this person produce something that looks and feels this good?" — and they'll answer that by feeling the site before reading a single word of copy.

Every visual decision here is load-bearing, not decorative:

• Deep warm navy (#0F1419) instead of pure black — distinct from both the generic dark-developer aesthetic and the light-editorial one. It sets a mood without announcing itself.
• Playfair Display paired with DM Sans — an editorial serif against a clean grotesque. The pairing argues for taste without a single decorative flourish.
• Left-anchored, asymmetric layout with hairline dividers, no cards or shadows — the absence of the shadcn-card-and-gradient template is itself the signal. Restraint reads as confidence here.
• A single amber accent (#E8975A) — used sparingly enough that it still means something each time it appears.

The technical choices map directly to the aesthetic ones — each is something a reader can go verify in the code:

• MDX-based case studies (next-mdx-remote/rsc + gray-matter), so each project reads as a narrative with real structure rather than a bullet list in a dialog box.
• Static generation at build time — no client-side content fetching, no layout shift.
• A boot-sequence on-load animation in pure React state, toggled via a single config flag (LOADER_ENABLED) — clean, swappable, and under 3KB.
• The View Transitions API for inter-page navigation, with a reduced-motion path that fast-dismisses rather than degrading into something worse.
• next/font/google with proper fallback metrics, so custom type loads without a flash of system font or a layout shift.

A few things on this site exist specifically as details for an attentive reader to notice:

• The boot-sequence loader is wired through a single config toggle — evidence of thinking in systems, not one-off effects.
• The hero headline's font weight shifts as you scroll — a single quiet motion, the kind of detail that rewards noticing rather than demanding attention.
• Every case study — including this one — follows the same numbered-block structure: a deliberate, repeatable format that turns "a list of work" into "the same argument, made seven times."

This case study is, structurally, the same kind of artifact it describes: a narrative about a build, written in the format that build established, living on the site that build produced. If the structure, pacing, and restraint of this page hold up, that's a more honest signal than anything I could write about the site in the abstract.

The site is doing its job if an engineer can trace a design decision back to a technical one and trust both — and if a client can feel, before reading a single case study, that the thing they'd be hiring for is already on display in front of them.