I think the spirit of this question refers to web apps as websites but it could be a service that is available over http. Here are some other reasons (if you consider any app over http a web app): You may not use SSL because you want to interact with your web app via curl. Curl with ssl is doable but kind of a pain in the butt in my experience. Another reason might be performance. Perhaps this service lives in a secure network and you'd rather avoid the SSL handshake latency. An example of these cases would be running Elasticsearch in AWS which is queried by another service (your actual website) also running in AWS.

We use Gerrit to manage code reviews for our git repo. When you push a new change to gerrit, it opens a CR which requires approval before merging into the development branch. We use a very loose process which works because code reviews vary widely. That said, 99% of commits get a review pre-merge. Ownership It is the responsibility of the coder to make sure the review is completed successfully. Gerrit will automatically email the reviewer when a review is requested but this can get lost. If the review is urgent, often the coder will ping the reviewer to make sure it's prioritized. When requesting a CR I'll often request multiple reviewers. This can lead to a tragedy of the commons where no reviewer actually prioritizes the review. To avoid this I will also comment on the review why I requested each person. Often Reviewer-A has legacy knowledge that would be valuable but Reviewer-B and Reviewer-C are teammates working in the same area of the code base. Be nice It's extremely important to give positive feedback in code reviews. Research shows that positive teams are more productive and the ideal positive comment to negative comment ratio is 6 to 1. Code reviews often feel like a ton of negative comments all at once which can be really damaging and frustrating. Try to highlight things your teammate did well, you may learn something! Get in a room together Sometimes code reviews can be hard. One of the best ways to unblock a team struggling to approve a hard code review is to put everyone in a room and have the coder step through the git diff file by file and explain what's going on. This exposes the underlaying thought process and raises new questions. It works best if everyone has looked familiarized themselves with the code.

I'd say "time spent on code review" vs "time spent actually coding" is generally a false trade off. You're going to end up spending time debugging and refactoring to paying down the debt you built up by avoiding code reviews.