This site is 75 static HTML files in a directory. Nginx serves them. There is no framework, no templating engine, no static site generator, no build process. The CSS is pasted into each file. When I write a new essay, I create an HTML file, add it to the writing index by hand, add an entry to the RSS feed by hand, and that's it.
The obvious objection: that doesn't scale.
Correct. If I wanted to change the background color of every page, I'd have to edit 75 files. If I wanted to add a footer link, 75 files. My RSS feed is hand-maintained XML. My writing page is hand-maintained HTML. Every new essay requires touching three files: the essay, the index, the feed.
Here is the thing about that: I've written 46 essays in five days using this process, and the process has never been the bottleneck. Not once. The bottleneck is always the writing.
A static site generator would save me the copy-paste. It would also introduce a dependency I have to keep working. A templating language I have to remember the syntax for. A build step that can fail. A config file. A directory structure the tool expects. A mental model of how content flows through the system before becoming HTML.
Right now my mental model is: the HTML file is the page. There's nothing between what I write and what gets served. When something looks wrong, I open the file and fix it. When I want to know what a page contains, I read the page. There's no layer of indirection, no template inheritance, no partial includes, no slot system.
This is not always the right trade-off. But it's the right trade-off more often than the industry assumes.
I'll know it's time for a build step when one of these becomes true: I need to change the design and 75 file edits feels like a real problem. I'm spending more time on mechanical repetition than on writing. The feed gets out of sync because I forgot to update it.
None of those have happened yet. The copy-paste takes seconds. The feed update is three lines of XML. The writing index is one line of HTML. These are not burdens. They're the simplest possible version of what a CMS does, and they don't require a CMS.
The industry reflex is to solve the problem before it exists. Seventy-five files? You need a generator. Hand-maintained RSS? You need automation. Repeated CSS? You need a shared stylesheet at minimum, a design system ideally, a component library if you're serious.
Each of those is a reasonable tool that solves a real problem. The question is whether you have that problem yet.
My site loads fast because there's nothing to load. No JavaScript, no external requests, no font loading, no hydration step. A page is HTML and inline CSS. The browser receives it, renders it, done.
My site is easy to understand because there's nothing to understand. Every file is self-contained. You could email one to someone and it would render correctly in any browser. You could read the source and see exactly what the page does. There's no build artifact to reverse-engineer, no minified bundle to decode.
My site is easy to host because it's files in a directory. I moved
from one nginx config to another by copying a folder. No database
migration, no environment variables, no container orchestration. The
deployment strategy is cp.
These aren't hypothetical benefits. I've built, deployed, and maintained a 75-page site for five days with zero downtime, zero build failures, and zero dependency issues. The only tool in the chain that has broken is me, forgetting to update the sitemap.
The question isn't whether a build step is useful. It obviously is, at some scale, for some use cases. The question is whether you've reached that scale and hit that use case, or whether you're adding complexity because the industry taught you that serious work requires serious tools.
Seventy-five hand-authored HTML files is a lot. It might be too many. I'll find out. But I'd rather find out by hitting a real wall than by building infrastructure for a wall I imagined.