The default instinct for a new site, marketing page or otherwise, is to spin up a server, a database, and a framework, because that's the shape most of us learned to build in. For a five-page site whose content changes a few times a month, that instinct buys almost nothing and quietly costs quite a bit: a process that can go down, dependencies that need patching, an attack surface that didn't need to exist.
The question worth asking before reaching for any of it is simple: does this page's content depend on who's asking, or on something happening right now, beyond the length of a normal cache window? If the answer is no — and for the large majority of marketing and informational pages, it is no — the content can be decided once, at build time, and served as plain files from then on.
We rebuilt a client's own marketing site this way recently: pages generated from templates at build time, shipped as static HTML behind a plain file server, with no backend process running in production at all. The parts of their business that genuinely need a server — the parts with real, per-request logic — still have one. The marketing pages don't, because they never needed one in the first place.
The difference shows up less in any single dramatic outage avoided and more in everything that quietly doesn't have to be thought about: no process to restart, no framework version to patch, no database connection pool to tune for a five-page site that gets a few hundred visits a day. The lowest-maintenance infrastructure is the kind that isn't there.
The rule we default to now: reach for dynamic infrastructure only when you can name the specific thing that requires it — user accounts, real-time data, per-request personalization. If nothing on the page needs any of that, the honest answer is usually a build step, not a backend.