1: A slim stack Every part of the stack will need maintenance every now and then. Some parts even introduce breaking changes and force you to alter your own co

1: A slim stack Every part of the stack will need maintenance every now and then. Some parts even introduce breaking changes and force you to alter your own code. The slimmer the stack, the less often you have to fix it. And the less often you have to fix or refactor your application. 2: A stack that values stability Linux is a good example. Linus Torvald: "We do not break userspace!" PHP is a another one. The core developers rarely introduce breaking changes. And when they plan to do so, there is usually an intense fight over it. 3: Acceptance Testing In the simplest form that means sending http requests to your web application and check if it returns the expected output. In my experience, acceptance tests find more real world issues then unit tests. 4: Write less code Writing the same functionality with less code has multiple advantages. One of them is that it will break less often. Much more could be said about it. Paul Graham brings up the value of terseness frequently: https://twitter.com/paulg/status/1068483193605681152 https://twitter.com/paulg/status/1068483193605681152 https://twitter.com/paulg/status/1126403387044573185 https://twitter.com/paulg/status/1126403387044573185 https://twitter.com/paulg/status/1056858408039735297 https://twitter.com/paulg/status/1056858408039735297 Less is more. This is actually one of the reasons why I named my account no_gravity.