[Klonoar]

This is so highly dependent on the individual developer or team that it is not applicable as blanket advice.

If you know you work faster without these, then fantastic - off to the races for you. But for every one of you I’ve met in my career, I’ve met 10 of the opposite.

It’s also just a classic line of premature optimization - you will likely rewrite big chunks as you grow and scale anyway, and the sooner you accept that and just focus on getting to market the better.

[quickthrower2]

It is not that I am a genius 10xer though! It is more that the traps of using someone else's code and dead ends probably take up as much time as starting from nothing. The hybrid approach is what I really use: stick the starter kit in another repo, play with it, transplant the best bits to the project, leave the stuff you hate. There are more ways to configure a NodeJS app or even front end build than there are atoms in the universe, and some don't play well with each other, so you have to get down and dirty at some point.

[j4yav]

I also agree this is the right way to use them. In cases where I didn't do this, I always ended up with some strange bit of the stack that I didn't use and didn't understand how it worked, and it caused some problems later. But copying and pasting relevant working bits into a new repo is a good learning exercise and also gets you going quickly.