Developer Portfolio
The Site You're Looking At Right Now
The Challenge
I needed a portfolio that shows real implementation depth, not just screenshots and short summaries. The goal was to present concrete case studies, technical tradeoffs, and outcomes in a format recruiters can scan quickly.
The Approach
Built with Astro for static-first performance, React islands for interactive components (terminal, tooltips, language switcher), and a single TypeScript data layer that powers both the website and the programmatic PDF resume. The PDF is generated client-side using jsPDF from the same data objects that render the pages - zero manual synchronization.
System Architecture
A static-first architecture: Astro generates all pages at build time as static HTML, with React components hydrating only where interactivity is needed (project filters, contact form, language switcher, terminal animations). A centralized TypeScript data layer (schema.ts + projects.ts + portfolio.ts) is the single source of truth for all content - both the web pages and the programmatic PDF resume render from the same data objects, guaranteeing they never fall out of sync. The i18n system uses React Context with localStorage persistence for seamless EN/FR switching without page reloads. Framer Motion handles all animations with viewport-triggered entry effects.
Built For
Technical recruiters, hiring managers, and engineering leads evaluating candidates - people who skim portfolios in under 60 seconds and need to quickly assess technical depth, project scope, and communication skills. The site is designed to answer "can this person actually build things?" within the first scroll.
Design Decisions
Why Astro instead of Next.js for a portfolio?
A portfolio is 95% static content. Astro ships zero JavaScript by default, making pages load instantly. React is only hydrated for interactive elements (project filters, contact form, animations). This gives us the best of both worlds: React DX with static site speed.
Why generate PDFs programmatically instead of maintaining a separate resume file?
A separate resume file is always out of sync with the website. By generating the PDF from the same TypeScript data layer, every resume download automatically reflects the latest projects, experience, and skills - zero manual maintenance.
Why a single data layer instead of a CMS?
A CMS adds complexity (hosting, API calls, content modeling) for a single-owner site. TypeScript files give us type safety, co-location with components, and zero API latency. The data is version-controlled with the code - `git log` is my audit trail.
Tech Stack
Outcomes & Impact
- 11 static pages generated at build time (index + 10 case studies)
- Programmatic PDF resume always in sync with website data
- Multi-language support (EN/FR) with localStorage persistence
- Zoom-resilient design from 50% to 200% browser zoom
- Strong Lighthouse performance from Astro's static-first architecture
💬 Behind the Scenes
“Yes, building a portfolio that includes itself as a case study is delightfully meta. But it's also the best proof of work - you're literally using the product while reading about how it was built.”