The Six-Script Doctrine — One Lifecycle, Six Commands

Open any of my seventy-two projects and you'll find the same six files waiting: setup, start, monitor, down, cleanup, deploy. Same names, same order, same job, every time. A trading engine, a security console, a content platform, a clipboard tool I use around the house — it doesn't matter what the thing is. The way you operate it is identical.

That's not tidiness. It's the single discipline that makes carrying this many projects possible without drowning in them. I call it the six-script doctrine, and it's the most boring, most valuable thing I do. The interesting work — the architecture, the hard problem each system actually solves — gets all my attention precisely because the operating layer never asks for any.

The six commands

Each script owns exactly one phase of a project's life, and the boundaries never blur. The discipline is in the refusal to let them.

• setup — bring a project from nothing to ready on a fresh machine: dependencies, environment, secrets scaffolding, the database, the works. Run once. The standard it has to meet is brutal and simple: a clean machine and this one command, with no human "oh, you also have to do this other thing." If setup needs a human to remember a hidden step, setup is broken, and I fix setup rather than documenting the workaround — because the workaround is a bug that pretends to be a note.
• start — run the thing. It checks that what it needs actually exists before it commits to anything expensive: is the image built, is the database reachable, are the ports free. It fails loudly and early with a clear message instead of dying silently ten minutes in, or worse, half-starting into a state you have to clean up by hand.
• monitor — tell me the truth about what's running: health, ports, logs, live state. Not a pretty dashboard — the fast, honest answer to "is this alive, and if not, where did it stop." The command I reach for first when something's wrong, because guessing is how small problems become outages.
• down — stop it cleanly. No orphaned containers squatting in the background, no leaked ports that the next project will collide with, no half-released resources. A clean stop is what makes the next clean start possible.
• cleanup — remove what shouldn't persist, reclaim disk and resources, leave the machine the way I'd want to find it. The script I'm grateful for the day a server is full and I need to know, with confidence, exactly what's safe to delete.
• deploy — push to production through the same path every single time: build, run the security checks, ship. The path I'd trust at three in the morning, because the whole point is that eventually I do run it at three in the morning, tired, and it has to be the same reliable sequence it was at noon.

Six verbs. The entire operational surface of any project, in the same shape, regardless of what's inside it.

Why sameness is the feature

The instinct, when every project is genuinely different, is to let the tooling be different too — to give each one bespoke commands that fit its special nature. Resist it. That instinct is how you end up with seventy-two snowflakes, each requiring you to relearn its quirks every time you return to it.

The variety should live inside the system — in the architecture, the domain logic, the actual hard problem the project solves. The operation of it should be aggressively, deliberately boring and identical across everything you own. That trade — interesting insides, boring edges — is the whole secret, and it's counterintuitive enough that most people get it backwards, lavishing creativity on their deploy scripts and shortchanging the architecture.

Here's the payoff, concretely. When the hundredth project answers to the same six commands as the first, I carry zero operational memory between them. I don't relearn how to run a thing I haven't touched in four months — I already know, because it's the same six commands it has always been and will always be. The cost of swapping a project back into my head drops to nearly nothing. And the cognitive budget I'd otherwise burn remembering bespoke incantations goes entirely to the work that actually moves the needle. Uniformity at the operating layer isn't a constraint on the work; it's what frees the attention the work needs.

Sameness is also what lets them compose

There's a second payoff that only shows up at scale, and it's the one that turns a portfolio into a system.

Seventy-two builds aren't seventy-two startups. They're nodes on one private mesh — and a mesh only works if its nodes share a protocol. The six scripts are that protocol. Because every project starts, stops, reports, and deploys identically, they slot together: I can orchestrate, monitor, and deploy across many projects from one level up, without writing custom glue for each one. The uniformity at the bottom is precisely what enables the leverage at the top. A tool that scans all my projects for port conflicts can exist because every project answers "what ports are you using" the same way. An operation that backs up or redeploys the whole fleet can exist because "down" and "deploy" mean the same thing everywhere.

This is the difference between owning seventy-two things and owning one system with seventy-two capabilities. The mesh is the actual asset — any single node can be extracted, hardened, and handed to a client or sold without disturbing the others — and the doctrine is the connective tissue that makes it a mesh instead of a junk drawer.

What it costs, and what it returns

I won't pretend it's free, because the up-front cost is exactly where people abandon it. Every new project pays a tax before it earns anything: you write the six scripts before you've written a single interesting line, and on day one, when you're itching to build the actual thing, that feels like pointless ceremony. The whole discipline is refusing to skip it in precisely that moment of excitement — because the moment you're most eager to skip the boring scaffolding is the moment you're guaranteeing the project becomes unrunnable later, when you've forgotten how it all fit.

The return is invisible until the worst possible moment, and then it's everything. The day a deploy goes sideways, you don't improvise under pressure — you run the same deploy you've run a hundred times, the one with the checks already baked in, and the muscle memory carries you when your judgment is rattled. The day a server fills up, cleanup already knows what's safe to remove, so you don't delete the wrong thing at midnight. The day you inherit your own project back after a season away, setup rebuilds it on a fresh box without a scavenger hunt through your past decisions. The tax is paid in a few calm minutes at the start. The dividend is paid in not panicking later — and unlike most things, it compounds across every project you own, because the discipline you bought once applies everywhere forever.

A worked example of the dividend

Let me make the payoff concrete, because "calm minutes later" is easy to wave at and hard to feel.

A project I hadn't touched in five months needed an urgent change — a dependency had a security advisory and I had to patch, verify, and redeploy it the same day. On a bespoke project this is where the afternoon disappears: rediscovering how it ran, what its environment expected, which undocumented step the original me had assumed I'd remember, where the deploy path actually went. Instead it was four commands. setup rebuilt it cleanly on a fresh box. start confirmed it came up, failing nothing. I made the patch, ran the tests, and deploy shipped it through the same checked path it had always used. Start to finish in under an hour, most of which was the actual code change — and I never once had to remember anything specific about that project, because there was nothing project-specific to remember. The six commands were the whole interface, and the interface was identical to the seventy-one others.

That's the dividend stated plainly: the doctrine turns "reopen a cold project under time pressure" — normally one of the more stressful things in this work — into a non-event. Multiply that across a portfolio and a few years, and the saved panic and reclaimed hours dwarf the up-front cost of writing six scripts you didn't strictly need on day one.

The doctrine is downstream of a deeper stance

Step back far enough and the six scripts stop being about scripts at all.

What they really encode is a stance toward building: ship deliberately, make the repeatable parts identical, and let reproducibility be a property of the system rather than a thing you hope you'll remember. That same stance shows up everywhere else in how I work. It's why I write architecture documents before code — the expensive mistakes are structural, and structure is cheap to change on paper and ruinous to change in production. It's why I build test-first — so "it works" is a claim a machine can verify, not a feeling I have. It's why I self-host everything on infrastructure I own — so the system depends on nothing I can't inspect and control. Different surface, same conviction: the boring disciplines, applied without exception, are what let one person operate at a scale that normally demands a team, and operate it without the whole thing decaying into a haunted house of one-off hacks nobody dares touch.

Anyone can build one impressive project on a burst of energy. The genuinely interesting question is what lets someone build seventy-two and still run all of them on an ordinary Tuesday without fear or heroics. The honest answer isn't talent and it isn't velocity. It's that they all answer to the same six commands — and that the person who built them got boring on purpose, in exactly the places where boring is what scales.

That doctrine is baked into everything on this site, including the engine you're reading it on. If you want systems that are still operable by a calm human years after they shipped — not just demoable on launch day, but operable, by someone who has forgotten the details, under pressure — that discipline is what gets you there. It's the least glamorous thing I do, and it's the reason the rest of it holds.

It's also the difference between code that's an asset and code that's a liability with a nice demo. A system nobody can confidently operate six months on isn't really owned, no matter who holds the repository — it's a hostage situation waiting for the day it breaks and the only person who understood it is gone. The six scripts are how I make sure that day never comes, on any project, for me or for whoever I hand it to. Boring on purpose, in the places where boring is what lets you sleep.

---

Summary

Every project ships with the same six commands: setup, start, monitor, down, cleanup, deploy. Not a framework — a doctrine, and the discipline that lets one person carry seventy-two projects.

Six Verbs. Each script owns exactly one phase of a project's life, identical across everything — the entire operational surface in the same shape, regardless of what's inside.

Boring Edges. Variety lives inside the system; operations stay deliberately uniform, so a cold project costs nothing to swap back into your head months later.

A Mesh Protocol. Identical lifecycles let seventy-two projects compose into one orchestratable system — a mesh with shared tooling instead of a junk drawer.

The Dividend. The tax is a few calm minutes up front; the return is not panicking at three in the morning, on any project, ever.

Code as Asset. A system nobody can operate six months later is a liability with a demo; the doctrine keeps every project runnable by a calm human, for whoever inherits it.