Static sites are underrated.

Every few months I watch someone spin up a Postgres instance, an auth provider, and a job queue to serve what is, functionally, a page of text that changes twice a month. I've done it myself. It's fun. It's also usually the wrong call.

The costs nobody counts

A backend isn't just the hour it takes to set up. It's the dependency upgrades, the cold starts, the environment variables in three places, and the low-grade anxiety that something is down while you're in a midterm. A static site has none of that. If the build passed, the site works — today, next month, and after two years of ignoring it.

What "static" actually gets you

• Free hosting, forever. CDNs serve files; files are cheap. A portfolio will never leave the free tier.
• Nothing to break. No server means no server errors. The failure mode is a failed build, which you see before anyone else does.
• Content as code. Posts are Markdown in the repo, so editing history is git history and backups are git clone.

Where the line is

The honest boundary: the moment your site needs per-user state — logins, comments, likes — static stops being enough on its own. But even then, the answer is usually one small API route or a third-party service bolted onto a static core, not a full backend. Start with files. Add servers when the files stop being enough.