← Back to work

Case study · Systems

The portfolio is also the proof

A personal site treated as a production system: public pages, hardened APIs and a private content studio on Next.js 15, React 19 and Cloud Firestore — with the security model, test suite and deployment discipline of a real product.

role

Everything — design, code, ops

timeline

Jun 2026 — ongoing

stack

Next.js 15 · React 19 · TypeScript · Firestore

output

This website + its admin studio

Fig. 01 — The home page mid-decode: the hero loads as dirty data and cleans itself into the headline.

02 — The problem

A portfolio should demonstrate the work, not just describe it

Most portfolios are static templates: edit a file, redeploy, hope nothing broke. I wanted the site itself to be evidence — content managed through a private studio, security that doesn't rely on secrecy, accessibility treated as a hard requirement, and visual changes caught by machines instead of my eyes. The constraint that shapes everything: one person maintains it, so every guarantee has to come from automation.

Constraint

One maintainer — correctness must be enforced by CI, not by vigilance.

Constraint

The browser talks to Firestore directly, so Security Rules are the only authorization boundary.

Constraint

Accessibility and visual regressions must fail the build, not wait for a bug report.

03 — Process

Three surfaces, one security story

STEP 01 · Architect

Public site, hardened APIs, private studio

Server-rendered public pages read Firestore through a tagged data cache; a rate-limited, injection-hardened contact pipeline; and a client-rendered admin studio gated in middleware before any markup is sent.

STEP 02 · Bridge

NextAuth identity, Firestore enforcement

Sign-in is Google via NextAuth (JWT, no database). A short-lived Firebase custom token bridges the session into Firestore so Security Rules can see the admin claim — and those rules are covered by an emulated allow/deny test suite.

STEP 03 · Guard

CI that looks at the site the way visitors do

Every push runs typecheck, lint, an 80%-gated unit suite, the Firestore-rules suite, and 78 Playwright checks — user flows, focus traps, axe WCAG scans and pixel-level visual baselines for every route, in both themes.

Fig. 02 — The admin studio's content library: every case study and article on this site is managed from here.

04 — Outcome

The site you're reading is the result

0

Playwright checks on every push

0%

unit-coverage gate on core logic

0

surfaces: site, APIs, studio

Everything you're looking at — this case study included — is served from Firestore and editable from the studio without a deploy. A per-request CSP nonce, tested security rules and per-route visual baselines mean changes ship with evidence instead of hope. It also settles the meta-problem: this portfolio can never claim more engineering care than it embodies.

Next project

An AI-assisted product-data pipeline at NiaDelta

View