Shipping happens once. Running is the condition you are in afterwards, and it lasts as long as the project does. The moment your work is live it can break at three in the morning while you are asleep, in a way you first hear about from a stranger. Nothing in the building phase rehearses that, because until now every failure has happened in front of you, on your own machine, at a time you chose.
This section is the small set of habits that keep a live project survivable for one person. None of it is advanced, and the setup is roughly an afternoon. What follows the afternoon is smaller and never quite finishes: a restore you re-test a few times a year, an hour of updates a month, an alert you delete when it starts crying wolf.
The first three build on each other: you have to be able to read a failure before being told about one is useful, and the backup in the third is what makes the sixth survivable. The last three are the recurring costs of being live: money, dependencies, and change itself.
- Errors and logs: where failures actually appear, how to read a stack trace, and how to turn "it's broken" into something an AI can fix.
- Knowing it broke before your users tell you: uptime checks, error tracking, and the gap between "it deployed" and "it works".
- Backups, and the day you need one: what to copy, how often, and why an untested backup is not a backup.
- What it costs to run, and what runs away: the bill at zero users, and the four ways it becomes a bill you did not plan.
- Updates and dependencies: security advisories, patch versus major, and letting an AI do the upgrade you actually read.
- Changing a live thing safely: small changes, known rollbacks, and why database migrations are the dangerous ones.