Skip to main content
Jose Leon
Back to work
Custom WebsitesMarketing Website

Alberto Olivero Portfolio Build

Visit live site (opens in a new tab)

The Problem

The site needed the same case-study architecture I use for my own portfolio, adapted for a friend's design work — but the build had diverged into an unused MDX rendering path and a security-flagged dependency version nobody had gone back to reconcile.

The Solution

Delivered a working Next.js portfolio reusing my own site's architecture, then a package-manager migration that surfaced and removed the dead MDX path and its dependencies, plus a documented performance and code-quality audit with findings ready to implement.

Timeline

Intermittent, March–July 2026

My Role

Full-Stack Developer

Personal project for a friend; solo developer.

Want to ask me a question?

What problem was this solving?What was your role here?How did you define success?What was your approach?
Alberto Olivero portfolio homepage hero reading "Hybrid Creative Direction & Visual Strategy for Purpose-Driven Brands" next to a hand-drawn character avatar

Built a Next.js portfolio site for an independent graphic designer to present branding and design work as structured case studies, then migrated its tooling and audited it for performance and code quality.

Overview

Alberto Olivero is an independent graphic designer working across branding, gig posters, and identity design. I built his portfolio site from scratch in Next.js — a home grid, about page, and a case-study system to present each project (Boosted, Caribombo, Diamonds, and others) individually — then came back later to migrate its tooling and audit it for performance and code quality.

Business Context

As a friend and independent developer, I took this on as a personal project: a working portfolio site Alberto could point people to. I started from the same site architecture I use for my own portfolio — home grid, about page, a case-study system with a detail template per project, and contact — reused as a starting template and adapted to his content instead of built from zero, so each design project gets its own page instead of a flat image gallery.

Challenge

Beyond the initial build, the codebase had inherited two real problems. First, a content-rendering path built around next-mdx-remote — carried over from the same MDX-based case-study pattern my own portfolio still uses — was pinned to a version flagged under CVE-2026-0969. Second, unlike my own portfolio, this build's case-study pages ended up rendering entirely from a plain TypeScript data file instead of live MDX, which meant the vulnerable dependency, its supporting libraries, and the components built around them were shipping unused — the same starting template, but a divergent implementation nobody had gone back to reconcile.

Solution

I built the site's core structure first: a home page with a project grid, an about page, and a case-study detail template driven by a central src/data/projects.ts file rather than individual MDX documents, plus the header, footer, and thumbnail/asset work needed to get real projects on the site. Along the way I patched the flagged next-mdx-remote dependency to v6 to close the CVE.

Later, migrating the project from npm to pnpm turned into more than a tooling swap. pnpm's strict, non-hoisted linking immediately surfaced a TypeScript error — Cannot find module 'mdx/types' — that npm's flat node_modules hoisting had been silently masking. Tracing that error confirmed the MDX rendering path was genuinely unused, so I removed it outright: the unused MDX loader and components, an orphaned example case-study file, and five dependencies that existed only to support that dead path — 146 fewer packages in the dependency tree, with pnpm run build and pnpm run lint passing clean afterward.

I then ran a full performance and code-quality audit against the live codebase. It surfaced a specific, prioritized list: multiple project images shipping as 700KB–2.2MB PNGs with no next/image sizes prop and no priority hint on the largest above-the-fold image; duplicated inline SVG icon markup between the home and about pages instead of a shared component; a usePathname() hook called separately per nav link instead of resolved once; project image filenames containing spaces; one project entry still carrying placeholder Lorem ipsum copy and images borrowed from other projects; and a missing metadataBase in the root layout. Those findings are documented and prioritized but not yet implemented against this codebase.

Outcome

The portfolio runs on a clean, correctly-scoped dependency tree: no vulnerable package versions, no dead rendering path, and a migration that validated the cleanup by catching a hidden type-resolution bug npm had been hiding. The performance and code-quality audit turned up a concrete, ready-to-execute punch list rather than vague advice — the next pass on this project is implementation, not further discovery.

My Contributions

  • Built the site from scratch: home project grid, about page, and a case-study detail template driven by a central data file
  • Patched a CVE-flagged next-mdx-remote dependency to the fixed version
  • Migrated the project from npm to pnpm, which surfaced a real hidden TypeScript module-resolution error masked by npm's flat dependency hoisting
  • Diagnosed that error back to an entirely unused MDX rendering path and removed it — components, loader, an orphaned example file, and five now-unnecessary dependencies (146 fewer packages)
  • Verified pnpm run build and pnpm run lint pass clean after the cleanup
  • Ran a full performance and code-quality audit, producing a prioritized, specific list of open findings (image optimization, next/image props, component duplication, file-naming hygiene, placeholder content, missing SEO metadata)

Technologies

  • Framework: Next.js 16, React 19
  • Styling: Tailwind CSS 4
  • Language: TypeScript
  • Package Manager: pnpm
  • Tools: Git, GitHub, ESLint

Gallery

Alberto Olivero portfolio homepage project grid alongside the "La Lechona" case-study detail page