Starting a project is usually easy. Returning to it after six weeks is the real test.
I now treat maintenance as a first-class feature. Every project has a short README with the purpose, the local development command, the production entry point, and the recovery path. Configuration is kept close to the code, while credentials stay outside version control. Logs are useful only when they include enough context to answer what failed and when.
Small release notes are surprisingly valuable. They record the reason for a change, not just the list of files touched. That makes it easier to decide whether an update is still needed later, and it gives future debugging sessions a timeline.
The other important constraint is scope. A personal service should earn its operational cost. If a feature adds another database, background worker, or external dependency, it should also remove a real limitation. Otherwise it is probably a demo, not a service worth maintaining.
The goal is not to eliminate all failure. It is to make failure legible, recovery repeatable, and the next change smaller than the last one.