Why there is no build step on this site
This page is hand-written HTML. There's no framework, no package manager and no compilation behind it — the evidence is what you're standing on.
Let me start with what isn't the argument: not that build tools are bad. There are excellent reasons for them, and they belong in most projects. This decision applies to this one site, and the reasoning goes no further than that.
What its absence removes
First, the source is identical to what runs. What I see in the editor is what the browser gets. There's no compilation step transforming something along the way, and no class of bug that only appears in production. When debugging, that saves more time than components would.
Second, there's nothing to update. No dependency tree where one security fix drags eight other packages along, and no tool that stops running on the machine two years from now. A static page nobody touches is the same page in five years — the subject of a separate piece on what happens to a neglected site.
Third, zero external requests. Rendering the page requires the browser to contact no foreign server: no CDN-hosted font, no embedded map, no analytics. The most important consequence isn't speed but that no data about the visitor reaches a third party — which is also why no cookie banner is needed.
with a build step
- source
- compile
- packages
- CDN
- browser
without one
- source
- browser
What I give up in exchange
This has to be said too, or the list above is propaganda.
There are no components. The header, the footer and the navigation exist as a separate copy on every page. If one of them changes, the change has to be carried through everywhere. That is the largest cost of this decision, and it can't be talked around.
There is no type checking and no compile error. A mistyped class name is stopped by no compiler: the page appears, just without styling. That is exactly the class of failure a build would catch.
And there is no automatic optimisation: the CSS isn't minified, the JavaScript isn't split. At this size that has no measurable consequence, but at a larger one it would.
The missing compiler is replaced here by a checking script that runs after every change: it looks at what a compiler would look at, and also at what no general tool could know about the site. There's a separate piece on that: what a machine should check on a website.
Where the limit is
This decision doesn't scale, and I don't claim it does. Any one of three conditions overturns it:
If the content isn't edited by the developer. The moment a client has to write text themselves, an interface is required — and from then on you need a system, not files.
If there are many pages of identical structure. At a few dozen, manual upkeep is still tractable. At several hundred, the copied parts start drifting apart, and nobody notices.
If the content is generated from data. Product lists, calendars, pricing — maintaining those by hand isn't a principle, it's a mistake.
The real measure
The question isn't whether there's a build step, but whether the system can be taken over. A hand-written site needs knowledge of HTML and CSS; a project built on eight packages also needs knowledge of the framework, its versions and its configuration.
Both can be right choices. The difference is that for the first, take-over readiness comes for free; for the second it is separate work — and when that work is skipped, you get the kind of system where the same one person always has to be called.
Questions on this topic
Isn't hand-writing HTML slower?
For the first page, yes; by the twentieth, not necessarily. What takes time isn't typing but maintaining the repeated parts. Up to a few dozen pages that stays manageable; where the structure changes often or there are hundreds of pages, generating is faster.
What does zero external requests mean?
That rendering the page requires the browser to contact no foreign server at all: no CDN-hosted font, no embedded element, no analytics. The most important consequence isn't speed but that no data about the visitor reaches a third party.
When is going without a build the wrong call?
When the content isn't edited by the developer, when there are many pages of identical structure, or when the site is generated from data. In those cases manual upkeep produces human error — precisely what a build would rule out.
How do you avoid repetition without a build?
You don't: the repetition stays, and that has to be accepted. What can be done is to stop the copied parts drifting apart unnoticed — that's what a checking script is for, one that examines the required agreements between pages.