No build step

Open our repository and something is missing. There's no dist/ folder. No node_modules in the deploy. No bundler, no compile step waiting between an edit and the live site. You change a file; it is the file that runs.

This is deliberate, and it's rarer than it should be.

The default everyone inherited

The modern web assumes a build. Source gets transpiled, bundled, hashed, and spat into a folder nobody reads. It works — until it doesn't. Toolchains rot. A site built on a 2021 toolchain often won't even compile in 2026: a dependency moved, a loader broke, the lockfile points at versions that no longer exist. The build was supposed to help; now it's the thing standing between you and a one-line fix.

What we do instead

The site is plain PHP 8.3, rendered in place on the server. Content comes from a headless CMS over a simple API; everything else is hand-written HTML, CSS, and a little JavaScript. Deployment is an FTP mirror and a cache purge — no CI, no container, no pipeline that breaks on someone else's breaking change. Where most stacks bundle and mangle, we keep a source file and a minified twin side by side, busted by a ?v=<mtime> query so the browser always gets the latest.

The honest tradeoff

It isn't free. We maintain those minified files by hand instead of letting a tool do it — a small discipline, one extra step per change. But the cost is small, visible, and entirely ours, not outsourced to forty dependencies we don't control.

Why it matters

The site loads in milliseconds and scores in the mid-90s on Lighthouse without a single optimisation plugin. There's nothing to lock us — or a client — into a vendor. And in ten years, someone can open these files and simply read them. That's the whole point.

A build step is a bet that the tools will still be there when you need them. We'd rather not gamble with a client's website.

Restraint isn't the absence of engineering. Sometimes it's the most of it.