Shipping a Developer Portfolio

Series Background: This is the first post in the Portfolio series. . What started as a minimal portfolio has evolved into a production-ready platform with comprehensive security, featuring CSP headers, rate limiting, Redis analytics, background job processing, and extensive monitoring. This series documents the complete journey from initial build to production deployment.

I built a modern stack that prioritizes server rendering, typed data, and tiny bundles.

Why App Router?

The Next.js App Router makes server components the default:

• Better performance: Initial loads are faster; most components render on the server.
• Improved SEO: Content fully renders before reaching the browser.
• Reduced bundle: Only interactive components ship JavaScript.
• Streaming: Built-in progressive loading via suspense.

I use client components only for theme toggling, the contact form, and sprinkle interactions.

Architecture cheat sheet

src/
├── app/           # App Router pages and API routes
├── components/    # Reusable UI components
├── content/       # MDX blog posts with frontmatter
├── data/          # Typed static data (projects, resume)
└── lib/           # Utilities and helpers

Stack deep dive

Next.js 15 + React 19

• App Router with server components by default

• Turbopack

  for lightning-fast dev server (production builds use Webpack)

• File-based metadata

  with zero config

TypeScript (strict)

• Type definitions for posts and projects ensure type safety
• Server routes validate payloads aggressively
• Strict mode catches errors at compile time

Tailwind CSS v4

• CSS-first mental model
• Dark mode via CSS variables, no class juggling

shadcn/ui

• Accessible Radix primitives (Dialog, Dropdown, Tooltip, etc.)
• Headless building blocks with CVA variants
• Copy-paste component library that you own

Deployment

Everything lands on Vercel with zero manual knobs. Analytics and Speed Insights are on by default, headers are set via vercel.json, and the whole thing stays fast.

Content Management

Blog posts live as individual MDX files in src/content/blog/, parsed at build time with gray-matter for frontmatter. This approach offers:

• Version control: Every post is tracked in Git
• Simple authoring: Write in Markdown with React components
• Type safety: Frontmatter is validated against TypeScript types
• Build-time rendering: Posts are statically generated for speed

MDX content is rendered with next-mdx-remote and enhanced with rehype plugins for auto-linking headings and GitHub-flavored markdown.

Takeaways

• Server components encourage: “does this need to be interactive?”
• Tailwind v4 eliminates config noise
• Git-backed authoring with type-validated frontmatter

Search and tag filtering are live. View counts are on the roadmap.

What’s Next?

After shipping, I hardened the site for production with security, performance, and developer experience improvements.