A static build is not a refusal to use a server. It is a decision about where the work should happen.
For a publishing site, most work can happen before a visitor arrives. The Markdown is parsed, the frontmatter is checked, the routes are rendered, and the final HTML is written to disk. The request path can then be deliberately boring: find a file and return it.
The useful boundary
The build is where content rules belong. A post without a description should fail there, not become a page with a blank social preview. A draft should never appear in the public collection. A future date should have one clear meaning.
The runtime has a smaller job. It serves HTML, styles, images, and the search index. That makes it easier to run the same output locally, in a container, or on a static host without changing the application.
The trade-off is visible
A scheduled post needs a scheduled build. Search needs an index generated after the HTML exists. A purchase flow needs a function or another service. Static does not mean featureless; it means each dynamic boundary is explicit instead of being hidden inside every request.
That explicitness is useful. It keeps the common path fast and makes the exceptional paths easier to reason about.