Most sites we build do not need a server at request time. When we notice that, we prerender everything and ship files.
The trade we are making
A statically exported site gives up anything that has to run per request: personalised rendering, on-demand revalidation, server actions. In exchange it gets a property that is hard to obtain any other way — there is nothing to be down. A file on a CDN has no cold start, no connection pool, no runtime dependency to exhaust.
For a company site, a documentation site, or a product page, that trade is almost always worth making. For a dashboard behind a login, it is not.
Deciding early
The cost of this decision is that it is difficult to reverse late. Features that require a request-time server tend to arrive quietly — an image optimiser here, a preview mode there — and each one moves the site off the static path.
So we decide at the start, write it down, and then hold the line: if a feature needs a server at request time, it has to justify pulling the whole site off static rendering.
What it does not mean
Static rendering is not the same as a site that never changes. Content still changes; it just changes at build time rather than at request time. A commit triggers a build, the build produces new files, and the files replace the old ones.