Next.js static export: when it's the right call (and when it isn't)

For marketing sites, documentation and content-heavy products, we often ship Next.js as a static export: the build produces plain HTML, CSS and JavaScript that any CDN or object store can serve. No Node server to patch, nothing to scale, and very little that can go wrong at 3 a.m.

What you get

• Speed. Pages are pre-rendered, so the first byte comes from the edge, not from a render queue.
• Cost. Static hosting is close to free, and traffic spikes don't change the bill much.
• Security. With no server runtime and no database connection, the attack surface is mostly your third-party scripts.
• Simple operations. Rollback is "deploy the previous folder".

What you give up

Static export means no API routes, no server-side rendering per request, and no middleware. If a page needs per-user data at request time, you either fetch it in the browser or you need a different architecture.

Our decision checklist

1. Is the content the same for every visitor? Static export fits.
2. Can dynamic bits (forms, search, comments) be handled by a third-party service or client-side calls? Static export still fits.
3. Do you need authenticated, personalised pages rendered on the server? Use a server runtime instead.
4. Does the content change many times a day? Consider incremental rebuilds, or a hybrid setup.

The hybrid option

Nothing says the whole product has to be one thing. A common setup is a static marketing site and docs, plus a separate application for the logged-in product. Each part gets the architecture that suits it, and the public site stays fast no matter what the app is doing.

If you're unsure which side of the line your project sits on, that's exactly the kind of question we're happy to look at with you.