- The project should start up with one click or one command. It's fine if I need to configure credentials or something similar, but beyond that, your project should be so easy to start that your mom could do it. If the project requires me to locally install a database, configure ports, or anything of the like, that's a shining red flag that things are very wrong.
- The underlying architecture and rationale should be documented and this document should be reasonably up to date. Whoever is the lead developer on the project should be responsible for this. Not all details need to be covered, but the main principles and the driving business requirements behind it need to be clearly stated and up to date. If there's no broad documentation, I consider the project to already be off the rails, not just heading that way.
- There should be a concept of testing. You don't need to have tests yet, especially if you're still prototyping, but you need to have a very clear idea of what you will test, how, and how you'll get there.
- Formatting isn't a discussion point. Whatever stylistic preferences there are are covered by linting and automatic formatting. If I clone the project, it should be reasonably hard for me to do things the wrong way and fairly easy to do them the right way.
- Branch management, code review, etc. All of this falls in the same pot for me, no one should have the ability to push directly to master, all changes need to go through review, pass lint, tests, etc before they can be merged. Doesn't matter if you're the lead dev or a summer intern.
You'll notice that all of the above are procedural issues, not code specific issues. I firmly believe that by nailing the underlying process first, you make it easy to build good software and hard to build bad software.