Document before you build — or you'll rebuild twice
Documentation is not what you write after the work. It is the work. A short guide for anyone about to start a process nobody has written down yet.
Useful when: How to record what you saw so a decision survives memory, turnover and disagreement.
**Who this is for:** anyone about to automate, delegate or hand off a process that currently lives only in someone's head.
**The problem it addresses:** a process you cannot describe in a paragraph is a process you cannot automate, delegate or improve. Most rework comes from skipping this step, not from bad execution.
Writing the document first forces the decisions that code — or a rushed handoff — would otherwise hide: who owns this step, what makes it done, what happens when it fails. Every one of those questions is cheaper to answer in a text file than in a system that's already live.
**When to use this:** before you build, automate or hire someone to take over a process. Not useful for one-off tasks you'll never repeat.
**What you can apply tomorrow:** pick one recurring process and write down, in plain sentences, who does it, what triggers it, what "done" looks like, and what happens when it breaks. If you can't finish that paragraph, that's the gap to close before anything else.
**What this doesn't solve:** it won't make a bad process good — it just makes the flaws visible early, when they're still cheap to fix. Teams that document first often move slower for the first couple of weeks, before things get faster.
Where this stops: These notes describe how I work. They aren't legal, insurance or engineering advice, and they don't replace an inspection or a professional review of your specific situation.