Why I Chose Next.js 16 App Router for My AI Portfolio
I rebuilt this site more times than I'd like to admit before settling on Next.js 16's App Router. Here's the actual reasoning, not just "it's popular."
The portfolio is a product, not a brochure
The brief I set for myself was: this shouldn't read as a static resume with a nav bar. It should demonstrate the same engineering judgment I'd bring to a real product — data-driven UI, typed content, proper SEO, and room to grow into interactive demos.
That ruled out a plain static site generator. I wanted Server Components for data-heavy pages (the project grid, the blog index) without shipping unnecessary JavaScript, and Client Components exactly where interactivity earns its keep — a theme toggle, a project filter, nothing more.
Metadata as a first-class citizen
The App Router's file-based metadata conventions (sitemap.ts, robots.ts, opengraph-image.tsx) meant SEO infrastructure lives next to the routes it describes instead of in a separate config file that drifts out of sync. generateMetadata per route made it trivial to keep titles and descriptions accurate as content changes.
MDX without a separate CMS
Blog posts live as MDX files with frontmatter, parsed at build time. No headless CMS, no database — just files in version control, which matches how I actually write: in an editor, with git history as the audit trail.
What surprised me
Streaming metadata and the maturity of ImageResponse for dynamic OG images meant I got production-grade social sharing images without a design tool — just JSX and CSS.
The App Router asks you to think in Server/Client boundaries from day one. Once that clicks, it stops feeling like a constraint and starts feeling like the framework doing your architecture review for you.