The Builder OS
Four moving parts — capture, decide, build, review. Everything else in the archive attaches to one of them.
Capture without deciding
The first failure of most systems is that capture and judgement happen in the same moment. You have an idea, and before it is written down you are already arguing about whether it is worth doing. That argument costs more than the idea.
Capture is a dumb inbox. One file, one shortcut, no folders, no tags. If writing something down takes longer than four seconds, the system is already leaking.
Capture is a dumb inbox. Judgement happens later, on purpose.
Decide once a week, in writing
Deciding continuously is what makes a week feel busy and end empty. Instead there is one decision window: everything in the inbox gets promoted, deferred, or killed, and the killing is the part that matters.
The output is a short list of what is running. Anything not on it is explicitly not happening this week — not delayed, not pending, just not happening.
Build in nine-day slices
Nine days is long enough to make something real and short enough that scope cannot drift. If a project cannot ship in nine days, it is two projects wearing a coat.
Cutting to nine days forces the useful question early: what is the smallest version of this that a real person could use on Monday?
Review in twenty minutes
The review is not reflection. It is three questions: what shipped, what stalled, and what will be deleted. Write one line for each and close the file.
Done weekly, this is the only mechanism that keeps the system honest — the archive of reviews is what eventually tells you which kind of work you actually finish.