This thought process goes beyond tech stack decisions and gets into software design decisions when you are writing code. Over-engineered solutions, and ones tha

This thought process goes beyond tech stack decisions and gets into software design decisions when you are writing code. Over-engineered solutions, and ones that seem like someone wanted to apply a design pattern everywhere take longer to implement and require more maintenance. If they go off the reservation of common solutions to common problems then when someone else has to pick up your code and grok what it does, it will take them longer, they may not understand it and could introduce bugs. Keep everything as simple as possible. For business purposes when it really comes down to it, the tech decisions don't matter. Sure you could choose the wrong technology for a problem but because there is a wrong option doesn't mean there is only one right option, there are probably many right options with different trade-offs. For example, if you have data with strong, well defined relationships, don't pick a data store that is NoSQL, pick a RDBMS. Does it matter which one? Not really, it matters more what your people are most familiar with since that will go a lot further. Pick based on your non-technical constraints - cost, skills, etc. This all changes if you are tinkering on a hobby project to learn something. In that case, pick whatever you want. That might help alleviate making boring tech decisions for your employer.