Context & Problem
Breaking into product management with a non-traditional background requires demonstrating PM skills, not just claiming them. A standard resume-style portfolio wouldn't cut it - I needed something that was itself proof of product thinking.
The meta-challenge: the portfolio needed to demonstrate the same skills it was showcasing - user research, spec writing, iterative development, and data-driven decisions.
Research & Discovery
- Analyzed 20+ PM portfolios to identify what worked and what didn't
- Researched what hiring managers and recruiters actually look at (spoiler: case studies and proof of structured thinking)
- Identified reference sites (similar PM portfolios) for interaction patterns and content strategy
- Key insight: depth beats breadth - one well-documented case study outweighs five bullet points
Solution & Approach
v1: Single HTML File
Everything in one file - validated the content strategy, tested with initial reviewers, identified what was missing. Proved the concept with zero infrastructure.
v2: Multi-Page Static Architecture
Refactored into 14 HTML pages with modular CSS/JS. Added Three.js hero particles, GSAP scroll animations, Chart.js skills radar, command palette, and dark mode. Full SpecKit workflow: constitution → spec → plan → 56 tasks across 8 phases.
v3: Next.js Migration (First Attempt)
Ported the static site to Next.js with App Router. Gained SSR, image optimisation, and route-based code splitting. But the architecture still carried over v2's patterns - it was a migration, not a rethink.
v4: Production Rebuild
Ground-up rebuild with a mature component architecture. MDX for case studies (write in Markdown, render with React components), dynamic OG image generation via Edge functions, GitHub API integration for live project stats, ISR for data freshness, Framer Motion for performant animations, and full accessibility (axe-core + Playwright tests).
v5: Hiring-Focused Refinement
Refined the production build around sharper positioning, stronger case-study writing, canonical resume sync, and more intentional recruiter flows. The product did not need a visual redesign - it needed clearer proof, tighter messaging, and better consistency across the site.
Visual Tour
The current build is intentionally multi-surface: the home page establishes positioning, the Projects page makes proof easy to skim, and the About page adds credibility without turning into a biography dump.
Implementation
Five decisions shaped the current architecture:
1. MDX for case studies - content as code. Each case study is a.mdx file with YAML frontmatter (metrics, navigation, stack) and Markdown body. The build system compiles them into React pages with automatic prev/next navigation, breadcrumbs, and SEO metadata. Adding a case study is a single-file operation.
---
slug: "aarchid"
title: "Aarchid - AI Botanical Intelligence"
metrics:
- label: "Diagnosis Accuracy"
value: 92
displayValue: "92%"
prevSlug: "portfolio-site"
nextSlug: "churn-analysis"
Context & Problem
Content renders with full React component support.../og/[...slug] route using @vercel/og. Social shares show a branded card with the page title, description, and domain - not a generic fallback.
3. GitHub API integration with ISR. The Projects and About pages fetch pinned repos, contribution graph, and language stats via GitHub's GraphQL API. Data revalidates hourly via ISR - always fresh, never blocking the build.
4. Component-driven design system. GlassCard, SectionLabel, MetricCounter, AnimatedSection - reusable primitives that enforce visual consistency. The command palette reaches every page from anywhere with fuzzy search.
5. Quality gates before every deploy. ESLint, TypeScript strict mode, Vitest unit tests, Playwright E2E and accessibility tests, and Lighthouse CI thresholds. No commit ships without passing all gates.
npm run lint # ESLint
npx tsc --noEmit # TypeScript strict
npm test # Vitest unit tests
npm run test:a11y # axe-core accessibility
npm run build # Next.js production buildOutcome & Metrics
| Version | Architecture | Focus | Key Features |
|---|---|---|---|
| v1 | Single HTML | Content validation | Narrative and proof-of-work baseline |
| v2 | Multi-page static | Interaction design | Three.js, GSAP, command palette, 14 pages |
| v3 | Next.js migration | Framework foundations | App Router, SSR, route-level organisation |
| v4 | Production rebuild | Scalable content system | MDX, OG images, ISR, GitHub API, a11y tests |
| v5 | Hiring-focused refinement | Narrative clarity | Resume sync, stronger case-study writing, tighter recruiter flows |
- Lighthouse: 95+ Performance, 100 Accessibility, 95+ Best Practices, 100 SEO
- Pages: 14+ including case studies, blog articles, and utility pages
- Versions: 5 shipped iterations in 3 months
- Testing: Unit (Vitest), E2E (Playwright), Accessibility (axe-core), Lighthouse CI
- Live: dhruvsinghal.codes
- Source: github.com/atavisticrystal6888/Portfolio-v4
Learnings
What Worked
Writing full specs before coding prevented scope creep and made each version's scope crisp. The SpecKit workflow (constitution → spec → plan → tasks) is a PM artifact in itself. MDX was the right content format - case studies are written in Markdown but render with full React component support.
What I'd Change
Would have jumped to Next.js at v2 instead of building a static multi-page site first. The v2 → v3 migration required rewriting all JS orchestration. The static site taught me architecture patterns, but the effort-to-learning ratio favoured an earlier framework adoption.