> so its trivial to add that to a project whether its Go or Node or whatever The thing I think you're missing, is that it's trivial TO YOU to do this, and of c

> so its trivial to add that to a project whether its Go or Node or whatever The thing I think you're missing, is that it's trivial TO YOU to do this, and of course you will understand it end to end and be supe productive. What happens when more people join you to work on that project? What happens when you leave and the next developer needs to understand all of this? What if he doesn't agree in the way you did things? Did you write thorough and detailed documentation for all the decisions you've taken? Can you guarantee it has no security flaws? What if the translations library you've picked has gone unmaintained because the developer that was building it as his side project got something more interesting to do on their weekends? That's the problem. Ending with a custom snafu that once made sense to somebody. Of course this can be made, and of course the next developer can pick it up, refactor, improve, etc. But from a business point of view it just makes literally zero sense. Think about all the time (and thus money) spent integrating things or writing your own infrastructure code and documenting it (because you're documenting it right?) and testing it (because you're testing it right) that could have been spent on actual business code. Compare that with the situation where you've just picked Rails/Laravel/Django/etc. The next developer knows what to expect. Knows how the most important parts work, has tons of documentation and material for learning, and when applied to the position they already knew more or less what to expect. The benefits of a "batteries included" framework is not the framework per se, is the community around it.