This is behind a paywall (but there's a trial period). It's very low-level and tactical, so probably hard to understand right now; but you should refer developers that you work with to it, and they should either have a flow similar to this one, or good reasons for using something different:
https://thoughtbot.com/upcase/videos/git-thoughtbot-git-flow
An overview of a process using Trello for product management.
More details about using Trello for product management.
A low-level walkthrough of how to perform productive code reviews.
A high-level perspective on how and why to implement a strong Code Review culture. (One of the best answers I've come across to the question, "How do I retain good developers and keep them happy?".)
The development section of thoughtbot's Playbook (the whole thing is worth a read).
Let's say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while. You might get a few more after you achieve a certain level of stability and maturity, but the general tendency is to overestimate the contents of your wallet. Clearly this model is approximate, but I think it helps.
If you choose to write your website in NodeJS, you just spent one of your innovation tokens. If you choose to use MongoDB, you just spent one of your innovation tokens. If you choose to use service discovery tech that's existed for a year or less, you just spent one of your innovation tokens. If you choose to write your own database, oh god, you're in trouble.
I believe Rails is this kind (the good kind) of "boring".
A counterpoint: Why I wouldn’t use Rails for a new company. The author's basic thesis is to "skate where the puck is going" in terms of developer enthusiasm/mindshare, which makes sense.
However, I don't believe that there is a clear successor to Rails -- yet. The author mentions Node.js, but I believe that it has already stabilized in mindshare. Elm and Phoenix are both showing promise, but they still aren't even close to having a rich ecosystem of "gems" and Stack Overflow answers like Rails has, so you will be spending some of your "innovation tokens" re-inventing things that the Rails community has already solved.
A guide to producing software estimates.
A counterpoint: Why software estimation is a losing game
I tend to agree with the latter.