A new laptop arrives, an old one fails, or a small website moves to another server. The difficult part is often not installing software. It is remembering the handful of decisions that made the previous setup work.
A setup note is a plain document that answers those questions while they are still fresh. It does not need to be a complete manual. A page that saves you three searches and one wrong turn has already done its job.
Record decisions, not every click
Start with the purpose of the setup and the few details that are easy to forget: where the files live, which command builds the project, how to publish it, and where to check when it fails. Add the version of a tool when an update could change the result.
For a personal site, that might be four lines:
Source: ~/sites/journal
Build: hugo --minify
Published files: public/
Check after publishing: home page, one article, RSS feed
The note is useful because it describes the relationship between those places. A long list of commands copied from a tutorial may be harder to understand six months later.
Keep secrets out of the document
A setup note can say where a credential is stored without containing the credential itself. Write “domain provider account, DNS section” or “password manager item named Journal Hosting.” This makes the note safer to sync or share when someone helps you troubleshoot.
If a setting matters, explain what it controls. “The web server serves public/; the source files are elsewhere” is more useful than a pasted configuration with no context. A future reader, including your future self, can then tell which part may be changed safely.
Include one recovery path
The best test of a setup note is a simple question: could you rebuild the essential part from it after losing the current machine? You do not have to rehearse a full migration every month, but it helps to verify that the source is backed up and that the build command still works.
Add a short “if something breaks” section. Name the first log to read, the last known good backup, and the step that puts the old version back. Those details are hard to invent calmly during an outage.
Update it when the work is done
The easiest time to maintain a setup note is immediately after a change. If you moved a folder, changed a build command, or replaced a service, spend two minutes editing the note before closing the task. A short accurate page is better than an elaborate page that describes a machine you no longer have.
Good documentation is often just a favor sent forward in time: enough context to make the next decision clear.