Top priorities for documentation: how to set up a production environment; how to get up a working copy running from scratch; any arcane command-line incantations or click sequences that you have to look up (or worse, work out by trial and error) more than twice. Document these from the get-go. In an emergency you’ll be glad you have them, and the next person you onboard will be grateful.

Second level priorities: complex algorithms; counterintuitive design decisions; complex high-level business logic, especially logic that’s spread across multiple methods/classes/modules. These are useful even for a solo developer if you end up stepping away from that area of the code for more than a month at a time. Once your team is big enough that people are regularly editing parts of the codebase that someone else wrote (or that depend on code someone else wrote) having this can save you hours of developer time per week.

Middling priority: documentation for HTTP APIs (and any other inter-process communication APIs). If you can auto-generate as much of this as possible, do so. I haven’t found it useful enough to put time into writing manually for a team of <15, but this is also on the hours per week list if the people consuming the APIs weren’t involved in writing or designing them.

Lowest priority: doc blocks and internal API documentation. Generally your developers can work this stuff out on their own. Depending on your language, API docs with function signatures may be auto-generatable, though the utility is limited if your developers are already using IDEs and other tools that provide autocomplete and lookups. Doc blocks with function descriptions are useful if the function does something unintuitive or too complex to be described in the name and should be written as part of general commenting practice as a matter of course.