Static by default, dynamic only when it earns it

A surprising number of marketing sites run a server on every request to produce a page that has not changed in three weeks. It works, until traffic spikes or the database has a bad afternoon, and it costs measurable milliseconds every time in exchange for nothing.

Our default is the opposite. A page is rendered once at build time and served as a file. There is no database to be slow, no cold start, no cache to invalidate incorrectly, and nothing to go down at three in the morning.

What that buys you

Predictable speed. A static file served from an edge network has no variance to explain. The slowest part of the request becomes the network, which we do not control anyway.

Fewer failure modes. A build either succeeds or it does not, and it fails on our machine rather than in front of a customer. A runtime error, by contrast, happens at the worst possible moment and only for some people.

Cheaper mistakes. When the content lives in the repository, a wrong price or a broken claim is a commit and a two-minute deploy, and it is visible in the diff for the rest of the project's life.

Where we do reach for a runtime

Two cases, and we ask for evidence before adding a third.

1. Something has to be received. A contact form has to accept a submission and send it somewhere. That is a small server action at one endpoint, not a reason to render every page dynamically.
2. Content genuinely changes per viewer. A logged-in dashboard is not a marketing page and should not pretend to be one.

Notice what is not on that list: a blog. Posts change when someone writes one, which is a deploy, not a request.

The part people worry about

The usual objection is that a non-technical teammate cannot publish without a developer. That is a real cost, and sometimes it is the deciding one. But the alternative (a content management system, a second set of credentials, a service with its own outages and its own bill) is not free either. For a site with a handful of pages and an occasional post, the honest comparison usually favours a file in a repository.

We reach for a CMS when more than one non-technical person publishes weekly. Below that, it is infrastructure bought for a problem nobody has yet.