IThe assumption
"Static" has come to mean "basic" — a brochure, a template, something you settle for when the budget runs out. That association is a decade out of date, and it costs businesses money, because a large share of the sites that genuinely need a server are paying for one they never use.
A static build means every page exists as a real HTML file before anyone visits. The server hands over a file. Nothing is computed per request.
IIWhat you actually give up
Content that must differ per visitor at the moment of the request: a logged-in dashboard, a price that changes per account, a search result computed from a live index. If a page needs those, it needs a runtime, and no amount of clever building replaces one.
That is the whole list. It is much shorter than most people assume.
IIIWhat you keep
Every design decision. Motion, transitions, oversized typography, interaction, a custom cursor, a multi-language route tree with clean crawlable URLs — none of these require a server. They are client-side or build-time concerns.
You also keep the things that are hard to buy: pages that arrive in one round trip, hosting that cannot fall over under load, and a deployment that is a file copy rather than a process to supervise.
IVWhere the line falls
The marketing site is static. The product is not. A studio site, a clinic's public pages and a restaurant's menu are static. The booking engine behind them, the patient records, the admin dashboard — those need a backend, and they should be built as one.
Confusing the two is the expensive mistake in both directions: paying for a runtime that serves brochure pages, or trying to force real application state into a build step.