How I Would Audit a Large Next.js Application

When a company asks me to evaluate their Next.js application, I follow a structured audit framework. Here's exactly what I look at and why.

1. Architecture and routing

What I examine:

• App Router vs. Pages Router (or mixed usage)
• Route organization and nesting depth
• Server vs. client component boundaries
• Layout composition and shared state patterns
• API route / Route Handler organization

Red flags:

• Mixed App Router and Pages Router without migration plan
• Every component marked "use client"
• Deeply nested layouts with unclear responsibilities
• Business logic in page components instead of shared modules

2. Data fetching patterns

What I examine:

• Server Components data fetching vs. client-side fetching
• Caching strategy (revalidation, tags, on-demand)
• API layer design (Route Handlers, Server Actions, external APIs)
• Error handling and loading states

Red flags:

• Fetching the same data in multiple places without deduplication
• No caching strategy (everything is dynamic)
• Client-side fetching for data available at build/request time
• Missing error boundaries and loading UI

3. Performance

What I examine:

• Core Web Vitals (LCP, INP, CLS)
• Bundle analysis (client JS size per route)
• Image optimization usage
• Font loading strategy
• Third-party script impact

Red flags:

• Client bundle > 200KB on content pages
• No dynamic imports for heavy components
• Unoptimized images or missing next/image usage
• Render-blocking third-party scripts

4. Component architecture

What I examine:

• Component size and responsibility
• Shared UI component library (or lack thereof)
• Prop drilling vs. composition patterns
• TypeScript usage and type safety

Red flags:

• Components over 300 lines with mixed concerns
• Duplicated UI patterns across features
• any types in production code
• No shared component library or design system

5. Developer experience

What I examine:

• Build and dev server speed
• Linting and formatting consistency
• Test coverage and CI pipeline
• Documentation (ADRs, README, component docs)
• Onboarding time for new engineers

Red flags:

• Build times over 2 minutes without investigation
• No CI checks on PRs
• No documented architecture decisions
• New engineers take months to make confident changes

Deliverable: Prioritized improvement roadmap

The audit output isn't a list of everything wrong. It's a prioritized roadmap:

1. Quick wins (1-2 weeks): Performance fixes, caching improvements, bundle reductions
2. Foundation (1-2 months): Component library, data fetching patterns, testing infrastructure
3. Strategic (3-6 months): Architecture migration, design system, observability

Each item includes estimated impact, effort, and risk — so leadership can make informed decisions about where to invest.