Launch Checklist · Next.js (custom)

Launching a custom Next.js app? Here is the full production checklist.

Hand-rolled means nothing is generated for you, including the parts people forget on purpose-built apps too.

A custom Next.js build gives you full control, and full responsibility for every layer: security headers, rate limiting, error monitoring, and access control all need to be explicitly added, none of it comes free with the framework. Next.js handles routing and rendering extremely well; it has no opinion on whether your API routes are rate-limited or your webhooks are verified.

The gaps here are less about the framework and more about what gets deprioritized under a real launch deadline, security and observability items that "can wait" until the deadline arrives and they get shipped without them anyway.

Next.js (custom)-specific

What gets missed on Next.js (custom) apps.

Missing security headers

HSTS, CSP, and X-Frame-Options are not set by Next.js by default. Add them explicitly in next.config or middleware.

API routes without rate limiting

Route handlers in the app directory have no built-in rate limiting. A public endpoint without it is an open invitation to abuse.

Edge vs. Node runtime assumptions

Code that works in the Node runtime can silently fail or behave differently on the Edge runtime. Verify which runtime each route actually needs.

FAQ

Common questions.

Does Next.js handle security headers automatically?

No. HSTS, Content-Security-Policy, and X-Frame-Options all need to be set explicitly, typically in next.config.js headers() or middleware.ts. Vercel adds a few sane defaults but not a full security header set.

What is the biggest gap in custom Next.js launches?

Rate limiting on API routes. Next.js route handlers have no built-in throttling, so a public endpoint without an explicit rate limiter (via middleware or a service like Upstash) is exposed to abuse from day one.

Other stacks