Building a Production-Ready Next.js Application

A production Next.js app is more than next build succeeding. It needs clear env rules, honest metadata, and failure paths users can understand.

Environment boundaries

• NEXT_PUBLIC_* only for values safe in the browser (portfolio URL, public site origin)
• Secrets stay server-only
• Document local defaults in README; override in hosting config

const portfolioUrl =
  process.env.NEXT_PUBLIC_PORTFOLIO_URL ?? 'http://localhost:4200';

Metadata that matches the page

Use the Metadata API per route:

export async function generateMetadata({ params }) {
  const article = await getArticleBySlug((await params).slug);
  if (!article) return { title: 'Not found' };
  return {
    title: article.title,
    description: article.description,
    alternates: { canonical: `https://example.com/blog/${article.slug}` },
  };
}

Typed content and routes

Prefer typed models for markdown frontmatter. Fail closed on unknown slugs with notFound() and a dedicated not-found.tsx.

Error and loading UX

Add error.tsx / loading.tsx where streaming or data fetching can fail. Empty states belong in the UI, not as silent blank pages.

Image and font discipline

• Use next/font for consistent typography without layout shift
• Prefer optimized images when you ship real covers
• Keep layout widths constrained for reading surfaces

Build as a gate

Treat next build as CI. Type errors and broken static params should block merge.

Conclusion

Production readiness is a set of boring habits: env hygiene, metadata, typed content, and explicit empty/error states—shipped every time, not as a pre-launch scramble.