Documentation people actually read
Four documents that suffice
A readme. What it is, how to run it locally, how to run the tests, and who to ask. It must be accurate — it's the document checked on every onboarding.
Architecture decisions. A page per significant decision: context, options, what was chosen and why. Short and dated.
Operations. What to do when something breaks, how to deploy, how to roll back.
Interface. From the code, so it doesn't age.
How to keep it fresh
Documentation that lives close to the code and is updated in the same merge request. A document elsewhere ages within two months, and worse — stays authoritative-looking.
What not to document
What the code says clearly. A comment describing a line is redundant; a comment explaining why an unusual approach was chosen is worth gold.
Going deeper
Check the readme on every onboarding: have a newcomer follow it literally and note every place they got stuck. That's the only way to find the silent assumptions all the veterans hold in their heads and nobody wrote down.