Next.js 16 Production Setup: How I Configure It for six-figure ARR Apps
Battle-tested Next.js 16 production configuration from Blossend Inc. App Router, Turbopack, Server Components, image optimization, and performance patterns powering 150K+ users.
See this stack in production. 150K+ users. six-figure ARR.
Free forever. Upgrade only when you're ready.
150K+ users · Ex-Amazon Engineer · Healthcare Innovation
No card charged today · 150K+ users · $0 to start
Next.js 16 is not just a framework update — it is the foundation that lets a solo founder run six production platforms. After deploying every version since Next.js 12, here is exactly how I configure Next.js 16 for production at Blossend with the App Router, Turbopack, and React 19 Server Components.
next.config.ts: The Production Config
The configuration file is where most developers go wrong. They either over-configure with experimental flags that break in production or under-configure and miss critical optimizations. Here is the philosophy: enable what the framework does best and stay out of its way.
I enable strict mode for React, configure image optimization with allowed remote domains for provider profile photos hosted on Supabase Storage, and set up redirects for legacy URL patterns from our earlier site versions. Turbopack is enabled for development, cutting our dev server startup from 8 seconds to under 2 seconds. In production, the standard webpack bundler handles the build because it produces more optimized output.
App Router File Structure
The App Router's convention-over-configuration approach eliminates routing boilerplate. Our structure follows a pattern: every route that needs SEO gets a dedicated folder with page.tsx, and shared layouts wrap groups of related pages. The (marketing) route group contains public pages like the blog and tech stack breakdowns. The (app) route group contains authenticated pages like provider dashboards and booking management.
Server Components are the default, which is exactly right for healthcare. Patient-facing pages like provider search results and profile pages render entirely on the server. The browser receives pure HTML with zero JavaScript bundle for these routes, which means instant page loads and perfect SEO indexing.
Performance Configuration
Three Next.js features have the biggest impact on our Core Web Vitals. First, automatic image optimization with the Image component handles responsive sizes, WebP/AVIF conversion, and lazy loading. Provider profile photos that would be 2MB JPEGs become 40KB AVIF files. Second, dynamic imports with next/dynamic split our booking widget and map components into separate chunks loaded on demand. Third, metadata objects in each page.tsx generate optimized <head> tags without client-side JavaScript.
TypeScript Strict Mode
TypeScript strict mode is non-negotiable. It catches null pointer errors, missing function arguments, and type mismatches at build time. In a healthcare application where a bug could expose patient data or break a booking flow, the compiler is your first line of defense. We run tsc --noEmit in CI before every deploy to ensure zero type errors reach production.
Environment Variables Pattern
Next.js distinguishes between server-only and client-exposed environment variables with the NEXT_PUBLIC_ prefix. We keep all sensitive keys — Supabase service role key, Stripe secret key, encryption keys — server-only. Only the Supabase anon key and public analytics IDs get the NEXT_PUBLIC_ prefix. This is enforced by a lint rule that flags any new NEXT_PUBLIC_ variable for review.
Middleware for Auth and Redirects
Next.js middleware runs on the edge before any page renders. We use it for three things: authenticating requests to protected routes by verifying Supabase session tokens, redirecting old URL patterns to new ones for SEO continuity, and setting security headers including Content-Security-Policy, X-Frame-Options, and Strict-Transport-Security.
The middleware file sits at the project root and uses a matcher config to only run on routes that need it. Public pages like the blog and tech stack articles skip middleware entirely for maximum speed.
Build and Deploy Pipeline
Our build pipeline is simple by design. Push to main triggers a Vercel production deployment. Push to any branch triggers a preview deployment. The build step runs TypeScript checking, ESLint, and next build in sequence. If any step fails, the deployment is rejected. Vercel's automatic rollback ensures that a bad deploy can be reverted in seconds.
Build times for our monorepo average 90 seconds for a full production build. Incremental builds on content changes take under 30 seconds. For a platform serving 150K+ users, this means we can ship multiple times per day with confidence.
Lessons From Running Next.js at Scale
The biggest lesson is to trust the framework defaults. Server Components by default is correct. Static generation where possible is correct. File-based routing is correct. Every time I fought the framework to do something custom, I created maintenance burden. Every time I leaned into its conventions, I shipped faster. Next.js 16 is opinionated, and those opinions are battle-tested across millions of production sites.