In a good documentation, IMHO, you must answer the following questions: - where can I find this functionality? - how is it done? - why is it done this wa

In a good documentation, IMHO, you must answer the following questions: - where can I find this functionality? - how is it done? - why is it done this way? You can do a lot with descriptive schemas, take a look at C4 models[1], they are simpler than UML and focus on a single part of your project at a time. This should answer the "where". Tutorials are a good way to present a use case and how to solve it using your project. This should answer the "how". Then, the most difficult part for me are ADR[2] (Architectural Decision Record), to document all decisions within the project. This should answer the "why". EDIT NB: Our ADR is our PRs since committing directly to master/main is forbidden and all code should be reviewed API Documentation is then done with comments/docstrings within the code itself, and usually the IDE knows how to read it and help you directly while you write code. [1] - https://c4model.com/ https://c4model.com/ [2] - https://adr.github.io/ https://adr.github.io/