The pull request fixes a typo in a heading. One word, one file. The pipeline that ships it runs for eleven minutes, spends most of them downloading and compiling, and bills every one of those minutes to the team's account. The site itself is a handful of templates and a stylesheet. Somewhere in the gap between the size of the change and the size of the ceremony sits a decision almost nobody remembers making: that a website, before it is allowed to be a website, must first be compiled.
That is the decision worth auditing this week. Every other compile step in software serves a machine that cannot run the source. This one serves a platform that has been able to run the source for years.
The Decade That Made It Reasonable
Grant the build step its decade in full, because it earned it. In 2012 the browser landscape was a disagreement with a user interface: half your visitors ran engines that understood only ES5, and none of them understood a module. The word import meant nothing to any shipping browser. So the tooling arrived, and it was rational from the first commit. webpack began in March 2012 as a side project of a master's thesis, by Tobias Koppers, precisely because modules had to be faked before they could be used. In September 2014 a tool called 6to5, written by Sebastian McKenzie and soon renamed Babel, made a career of translating tomorrow's JavaScript for yesterday's browsers. TypeScript, from 2012, is a language whose entire premise is a compiler. And under HTTP/1.1, gluing a hundred files into one bundle was simply good manners towards the network.
None of that was cargo cult. For that decade, the build step was the only professional way to write modern code for the browsers people actually used. The counter had a real product on the shelf, and everyone bought it for a reason.
The Platform Caught Up; The Default Did Not
Then the gap closed, quietly and completely. By May 2018, when Firefox 60 joined the rest of the field, every major browser executed ES modules natively. Import maps closed the last practical hole in March 2023, when Safari 16.4 shipped them and bare import specifiers began working everywhere without a bundler. Node.js stopped needing a compiler for TypeScript's types in January 2025: since version 23.6 it strips them natively, unflagged, and simply runs the .ts file. This is what type stripping means: the annotations are replaced with whitespace and the file runs as the JavaScript it always was.
Some platforms drew the conclusion. Ruby on Rails made no-build the default for new applications back in December 2021, serving plain ES modules through import maps; its author, David Heinemeier Hansson, put the argument in one line: you can't get faster than No Build.
And the JavaScript mainstream? When the React team retired Create React App in February 2025, the farewell notice pointed to frameworks and to build tools such as Vite. The scaffold still installs the compiler first and writes hello world second. The industry has treated slow builds as the problem for a decade and answered with a faster bundler every time: Grunt, Gulp, webpack, Rollup, Parcel, esbuild, Vite, Turbopack, Rolldown (call it nine generations, or eight, depending on whether you count Vite's two engines separately). esbuild advertises itself as 10 to 100 times faster than the generation before it. A faster build step has always been on offer. The option of no build step, for a large class of projects, somehow never made the menu.
The Meter
Here is the part of the audit where the invoice arrives, because the build step is also a billable unit. GitHub meters hosted Linux runners at $0.006 per minute once the free allowance is spent. Netlify's free tier includes 300 build minutes a month; the next tier costs $19. Vercel includes 6,000 minutes and then charges per additional minute, up to $0.126 on its fastest hardware. None of these meters runs when there is nothing to build. The eleven-minute pipeline for the one-word typo is not an accident of your configuration; it is the business model working as designed. The platforms did not invent the build step, and to be fair they also sell you the cache against it, but they have no earthly reason to ask whether you need it at all.
What the installer pays is broader than the meter. The onboarding day lost to assembling a toolchain before the first line of product code. The production bug you debug through a sourcemap into code whose shape you never wrote. The half-day a broken lockfile takes out of a release. The compiler chain that is itself a dependency tree with its own maintenance and its own supply-chain surface. And the counter's strongest case deserves saying plainly: a 400,000-line TypeScript codebase or a genuinely large single-page application earns its compiler every day. This audit questions the default, and leaves the tool its earned place.
The Point
A large share of the working web is server-rendered pages, content sites, internal tools, and the modest sites that are three templates and a stylesheet. For that share, in 2026, the compile step is a habit with a meter attached, carried forward from a browser landscape that stopped existing years ago. The default deserves to be inverted: start with no build, and add one when something you can measure demands it. Plenty of projects will pass that test honestly. The rest are paying for a gap that closed years ago.
Every other compile step in software serves a machine that cannot run the source. This one serves a platform that has been able to run the source for years. A build step nobody can justify is a standing order, renewed on every push.