Why I Chose Next.js 16 for My Portfolio

I've architected systems that handle thousands of requests per second, processed billions in transactions, and shipped apps used by millions. But when it came time to build my own portfolio, the stack decision was surprisingly hard.

The Requirements No One Talks About

[Expand: Why a portfolio site for a CTO has different requirements than a typical dev portfolio. Performance as credibility. The site IS the resume.]

Why Not Astro, Remix, or Plain HTML?

[Expand: Evaluated alternatives. Astro great for static but needed dynamic (PostHog flags, Sanity CMS, contact API). Remix solid but ecosystem. Plain HTML — not when you need 11 case studies with SSG. Next.js 16 hit the sweet spot.]

Server Components Changed Everything

[Expand: Companies page — zero JS shipped. Products/Services — server-rendered with metadata. Only pages that NEED interactivity (PostHog, contact form, theme) stay client. The server/client split pattern.]

The Embedded CMS Play

[Expand: Sanity Studio embedded at /studio. AI editorial workflow. Why I didn't go headless-only. The CSS :has() trick to hide nav in studio. Blog with feature flag — ship infrastructure before content.]

What I'd Do Differently

[Expand: Honest retrospective. Things that surprised you. Tailwind 4 migration timing. ESLint 9 flat config pain. React 19 useRef changes. What you'd tell another CTO building their site.]

A portfolio for a fractional CTO is less about aesthetics and more about demonstrating judgment under real constraints: performance, maintainability, observability, and authoring experience.

You treated the site as a production system, not a vanity project, and your stack choices reflect that.

Framing the Problem Correctly

You didn’t build a static brochure; you built a small product:

• 11 case studies (some under NDA constraints)
• 4 service pages
• A progressively rolled-out blog
• A contact pipeline with rate limiting and bot resistance
• A CMS that lives where you actually work, not in a separate SaaS tab

The hidden requirement: every technical decision is itself a portfolio artifact. Founders are evaluating your judgment by how the site behaves before they read a word.

That makes Core Web Vitals, reliability, and author experience first-class concerns, not afterthoughts.

Why Next.js 16 Was the Right Call (For This Problem)

You evaluated Astro, Remix, and even plain HTML honestly and rejected them for concrete reasons:

• Astro: Excellent for static marketing sites, but you needed:
• PostHog feature flags influencing render paths
• Embedded Sanity Studio
• API routes with rate limiting
• A cohesive full-stack story without bolting on a separate backend

Astro could be made to work, but you’d be solving framework gaps instead of shipping.

• Remix: Strong data-loading model, but:
• Smaller ecosystem
• Less turnkey Vercel integration
• Rougher shadcn/ui story at the time you started

For a non-billable personal project, friction matters more than theoretical elegance.

• Plain HTML: Fine for a handful of pages, but with:
• 11 case studies
• CMS-driven metadata
• A real blog with SSG

you either reinvent a build system or accept a maintenance nightmare.

Next.js 16.1.6 with the App Router gave you:

• SSG for case studies
• SSR where needed
• First-class API routes
• Vercel-native deployment
• A mature server component story

The key is alignment with your mental model: server components as a rendering budget tool, not just a performance trick.

Server Components as a Discipline Tool

You used server components to enforce a healthy default:

• Companies page: pure server component, zero client JS. It’s a static grid of logos; there’s nothing to hydrate.
• Service pages and case studies: server-rendered, metadata generated at the route level, clean HTML for Google, minimal client bundle.

Then you were explicit about where the client is justified:

• PostHog tracking
• Contact form with rate limiting feedback
• Theme toggle
• Framer Motion hero animations

"use client" becomes a budgeted decision, not the default. That’s exactly the discipline most React codebases lack.

Embedded CMS as a First-Class UX

You treated the CMS as part of the product, not an implementation detail.

• Sanity Studio v5.12.0 embedded at /studio in the same Next.js app
• next-sanity 12.1.0 for tight integration
• No subdomain, no context-switching into another tool

Author experience directly affects output:

• Lower friction → more writing
• One-click publishing → more frequent iteration

You went beyond a text box:

• AI editorial workflow with quality scoring (readability, structure, keyword density, SERP relevance)
• SERP preview
• Internal linking suggestions