I don't know. Based on my experience I firmly believe that between not-invented-here vs invented-here syndromes, many more projects fail because they try to do

I don't know. Based on my experience I firmly believe that between not-invented-here vs invented-here syndromes, many more projects fail because they try to do too much themselves. Especially in startups. For anything that is not the laser-focused core offering of your product, pick a good enough library and be done with it. Invariably, most problems are such that you can get 70% of the implementation done (the fun part) with a reasonable amount of work, but the last 30% (all the little details that you didn't thought of) take +70% of the time. And you also need battle-test it. For example, React is interesting, because it is battle-tested by Facebook, not just because of the approach it took to the rendering. Good candidates for underestimating the amount of work: Anything with i18n and l10n (dates, money). Anything with threads (futures and promises library). Anything with small errors causing cumulatively bigger errors (scientific calculation and money). Anything integrating with the real-world outside of your app (sending email) Anything with charts.