Back to EngineerView-Portfolio
Case studyMay 20, 202612 min read

EngineerView Portfolio: production Next.js 16 at voxhash.dev

How the VoxHash portfolio ships on Next.js 16 and React 19 with GitHub-driven projects, hardened contact flow, Giscus comments, production Lighthouse baselines, and SSR project listings.

Live demoGitHub
nextjstypescriptportfolioperformanceseo

Why this project exists

EngineerView Portfolio is the production codebase behind voxhash.dev. It is not a generic theme: it integrates live GitHub data, Medium writing, optional speaking video APIs, a hardened contact pipeline, and operational docs (content workflow, Lighthouse baselines, Dependabot) so the site stays fast and maintainable without a CMS.

Stack and deployment

| Layer | Choice | Role | |-------|--------|------| | Framework | Next.js 16 (App Router, Turbopack) | SSR/ISR pages, API routes, OG images | | UI | React 19, Tailwind CSS 4 | Components, dark/light theme | | Hosting | Vercel | Production deploys from main | | Email | Resend + @react-email/render | Contact notifications | | Comments | Giscus → GitHub Discussions | Blog engagement | | Quality | Jest, Playwright smoke tests, Lighthouse CI | Regression and perf gates |

Tagged releases (for example v3.1.1) document maintenance work: production smoke tests, two-run Lighthouse baselines, /projects SSR performance, and dependency automation.

Architecture highlights

GitHub as the project catalog

The /projects route server-renders repositories for GITHUB_USERNAME (VoxHash) with revalidate = 3600, aligned with getFetchCacheOptions('DYNAMIC') in lib/github.ts. The client layer only handles filters and grouping—no client-side fetch on first paint, which improved production Lighthouse performance on /projects from the low 50s to ~80+ after removing duplicate card grids and post-load API calls.

Content without an admin UI

Maintainers edit JSON/TS data (data/pinned.json, data/timeline.ts), env vars, and external platforms (Medium, YouTube). The content workflow doc documents the full flow: branch → PR → Vercel deploy → optional production baseline refresh.

Contact and abuse resistance

The contact form uses honeypot fields, optional signed tokens (/api/contact/token), and Cloudflare Turnstile when configured. The API returns human-readable result.message values and fails closed in production when email is not configured.

SEO and discovery

Per-route metadata via lib/seo, dynamic /api/og images, JSON-LD (Person, Organization, Article, SoftwareApplication), sitemap entries for static routes plus GitHub projects and Medium posts, and Search Console verification in production env.

Performance workflow

Production Lighthouse runs are stored in docs/lighthouse-baseline.md. Two runs on the same deploy confirmed stable category averages before tightening CI thresholds. Weakest routes remain /feed (~75 performance) and some resume/contact variance—documented for future caching and asset work (edge-caching.md).

Operations

  • Dependabot — weekly npm and GitHub Actions updates (majors reviewed manually per SECURITY.md)
  • E2E — Playwright smoke tests on /, /projects, /blog, /contact, /resume, /speaking in CI
  • Metrics — /metrics-dashboard is noindex for internal Web Vitals review

What we learned

  1. Align page revalidate with fetch cache TTL — avoids stale HTML with fresh JSON or the reverse.
  2. Measure production twice before raising Lighthouse gates—localhost CI scores do not match CDN + analytics on voxhash.dev.
  3. Keep case studies on-repo — this MDX document is the first; it links from the GitHub project page and is indexed in the sitemap.

Links