Problem
Breaking into product management with a non-traditional background requires demonstrating PM skills, not just claiming them. A standard resume-style portfolio would not do that; the site needed to be proof of product thinking in itself.
The meta-challenge: the portfolio had to demonstrate the same skills it was showcasing, from research and spec writing to iteration and honest measurement.
Users
Recruiters and hiring managers who skim, and interviewers who read one case study deeply. Before building I reviewed a set of PM portfolios (self-reported: 20 or more) and what reviewers say they look for. The takeaway that shaped every version: depth beats breadth, and one well-documented case study outweighs five bullet points.
Decision
Trade-offs
- Specs before code. Each version started from a written spec (constitution → spec → plan → tasks), which kept scope crisp at the cost of slower starts.
- Static first, framework later. v2 was a multi-page static site before the move to Next.js. It taught architecture patterns but cost a rewrite; in hindsight I would have adopted the framework at v2.
- Honest gates over headline scores. Lighthouse CI asserts thresholds (below), rather than the site quoting a best-case score from one run.
What shipped
| Version | When | Architecture | Focus |
|---|---|---|---|
| v1 | Jan 2026 | Single HTML file | Content-first draft |
| v2 | Jan–Apr 2026 | Multi-page static (14 HTML pages) | Interaction design: Three.js, GSAP, command palette, dark mode |
| v3 | Jan–Apr 2026 | Next.js migration | App Router, SSR, route-level organisation |
| v4 | Apr 2026 (repo started 18 Apr) | Production rebuild | MDX case studies, OG images, ISR, GitHub API, accessibility tests |
| v5 | Aug 2026 | Hiring-focused refinement | Sharper positioning, resume sync, stronger case-study writing |
| v6 | Sep 2026 | Case studies as product pages | Decision-first case studies, claim audit |
v2 and v3 have no dated record, so they are placed only between v1 and the v4 repository's first commit. The release notes for the current site are on the changelog, the tools behind it on uses, and the thinking behind treating it as a product in Building a portfolio as a product.
The v2 build was run through the full spec workflow: 56 tasks across 8 phases (self-reported from the project notes at the time).
Under the hoodArchitecture and implementation
MDX for case studies. Each case study is a .mdx file with YAML frontmatter (metrics, navigation, stack) and a Markdown body. The build compiles them into React pages with prev/next navigation, breadcrumbs and SEO metadata.
---
slug: "desktasks"
title: "DeskTasks — The Task Widget That Stays Out of Your Way"
metrics:
- label: "Failures at the 15 Sep 2026 release gate"
displayValue: "0"
kind: product
prevSlug: "aarchid"
nextSlug: "cohort-retention-studio"
---
## Problem
Content renders with full React component support...
Dynamic OG images at the edge. An /og/[...slug] route renders a branded card per page with next/og, on the edge runtime.
GitHub data with ISR. The Projects and About pages fetch repository data through GitHub's GraphQL API and revalidate hourly.
Reusable primitives. SectionLabel, MetricCounter, ScrollReveal and similar components keep the visual system consistent; a command palette reaches every page.
Quality gates. CI runs four jobs on every push and pull request to main:
# Job 1: lint + unit
npm run lint # ESLint
npm test # Vitest unit tests
# Job 2: build
npm run build # Next.js production build (includes type checking)
# Job 3: Playwright e2e + a11y
npm run test:e2e # runs tests/e2e and tests/accessibility
npx playwright test tests/accessibility # the axe-core checks on their own, locally
# Job 4: Lighthouse CI
npx @lhci/cli autorun # thresholds from lighthouserc.json
Validation
What the gates actually enforce, from lighthouserc.json: accessibility must score at least 0.9 and SEO at least 0.95 (failures), while performance and best practices at 0.9, plus FCP, LCP and CLS budgets, are warnings only. Accessibility is also checked with axe-core through Playwright. CI runs these on push and pull request.
Performance, measured 2 October 2026. On a local production build, Lighthouse 13.5.0 mobile tests with simulated throttling improved Home LCP from 4.30 s to 3.23 s and its performance score from 79 to 93 (median of three runs). Across five tested page types, final mobile LCP was 3.12–3.34 s and measured lab CLS was 0. The under-2-second target was not met. These are local lab results, not field Core Web Vitals or a guarantee for visitors.
Accessibility, checked 30 Sep 2026. axe-core reported zero violations at the WCAG 2.2 AA tags across 36 routes, in two themes and two viewports.
Colour contrast is partly machine-unverifiable where text sits on gradients; axe marks those nodes "needs review", and I checked them by pixel sampling instead. None of this replaces a screen-reader pass or a test on a physical phone; both are still open.
The live site at dhruvsinghal.codes returned HTTP 200 on 30 Sep 2026. There is no conversion data: I cannot attribute interviews to the site.
Limits and next
- No outcome metric. Recruiter behaviour on the site is not measured, so the evidence is the build and its gates, not hiring outcomes.
- Screenshots are dated. The header image and gallery show the October 2026 build; later changes will not be in them until they are recaptured.
- What I'd change: jump to Next.js at v2 instead of building a static multi-page site first. The v2 to v3 migration required rewriting all the JavaScript orchestration.
Credits
Solo: spec, design and build. Source: github.com/atavisticrystal6888/Portfolio-v4.
