Every deploy of every project we run goes through my hands, and I want to explain why, because from the outside it can look like a control habit and it is not one. A deploy is the moment where responsibility stops being abstract, where everything the team decided becomes something a browser either renders or does not, and I believe the person who carries the accountability for a system should be the same person who performs that act, feels its duration, and sees its result with their own eyes. We have written before about concentrating responsibility in one person, and this post is the operational half of that conviction, which is that accountability without contact with the actual shipping is accountability in name only.
Feedback Should Arrive While the Change Is Still Warm
When I build and deploy from my own machine, the feedback is immediate and it is mine: the build either succeeds in front of me or fails in front of me, the preview answers my questions while the change is still warm in my head, and the deploy itself tells me within seconds whether production accepted what I offered it. The alternative that most of the industry runs is a pipeline on a distant runner, and I understand exactly why that exists, because once you have dozens of people merging into one branch you need a gatekeeper that never sleeps. What it costs, at our scale, is distance: the environment that builds your code is one you have never seen, looked after by people you will never meet, and it can change beneath you between one deploy and the next, a new image here, a new toolchain default there, a small surprise introduced beyond your knowledge and discovered, if you are lucky, before your users discover it for you.
A build environment you cannot inspect is a colleague you have never met making decisions in your name.
The Artifact Is the Answer
There is a simpler way to say all of this, which is that I want to know the exact code that runs our production, and the only way I know to be certain of that is to make the tested thing and the shipped thing the same thing. On this site the whole pipeline fits in four commands:
bun ssg # render the site into ./dist
bun preview # serve ./dist locally, exactly as built
bun cf:share # expose ./dist through a temporary tunnel
bun cf:deploy # upload ./dist as-is, no rebuild
The folder that the build writes is the folder that the preview serves, the folder that the tunnel shares, and the folder that the deploy uploads, byte for byte, which means the pages I click through on my machine before shipping are not a reconstruction of what visitors will see but the very thing itself. A setup that rebuilds on the way to production breaks that identity in a way that is easy to miss, because two builds from the same source are the same only in theory: the toolchain has versions, the build has its own dependencies, and any of them can drift between your machine and the distant one. When someone reports a bug on a page, I can open precisely the bytes they hit, and being able to do that is what knowing your production actually means, which is also why the local preview is not a convenience but the rehearsal with the real set, the last honest look at the thing before it meets its audience.
That rehearsal is not only for me, because a preview that lives on my screen answers only my questions. When a build is ready we expose the same folder through a temporary tunnel and share the address with QA, with someone in house, or with the client, whoever holds the final check mark for that release, and what they click through and approve is not a staging copy of the build but the build itself, the same bytes that production will serve once we switch it over. An approval given on that address means something an approval on a staging environment never quite can, which is that nothing stands between the thing they accepted and the thing that goes live: no rebuild, no promotion step, no second environment with its own opinions, just the same folder meeting a wider audience.
My Machine Became Your Machine
There is a joke as old as our industry, "it works on my machine," and it has always sounded different to me than to most, because in my early years we shipped software together with the hardware it ran on. You delivered a machine, you installed your work on it, and the sentence stopped being a joke or an excuse, since my machine was quite literally about to become your machine, sitting in your office, running my code. The joke was born later, when the artifact started traveling separately from the environment and the gap between the two became a place where bugs could live. Deploying personally, from a machine whose state I know, closes that gap again, because the output of my machine becomes your production without being reinterpreted along the way, and the old sentence turns from a punchline back into a plain description of how things work.
The Same Discipline at Any Address
None of this depends on where the bytes land. This site happens to deploy to Cloudflare, whose tooling accepts a ready-made folder and uploads it as-is, and that fits the discipline perfectly, but we work the same way when the target is a VPS or a machine in a client's own rack, which is the arrangement we argued for in owning where your software runs: build the artifact locally, transfer it, run it. The principle is not a platform feature but a relationship between the person and the thing being shipped, and it survives any address you point it at.
None of this is an argument that pipelines are wrong, because at the scale they were built for they are the only sane answer, and a team of a hundred cannot gather around one laptop. It is an argument that at the scale most business software actually lives at, someone should be able to say with a straight face exactly what is running in production right now and why, and that the shortest path to that sentence is a local build, an honest preview, and a person who ships what they tested.