I don't think this can ever be totally cut and dried. There is a heuristic when either using external or developing one inhouse is obvious, but if neither appl

I don't think this can ever be totally cut and dried. There is a heuristic when either using external or developing one inhouse is obvious, but if neither applies then finding the best solution requires careful thinking. The obvious place to develop a library inhouse is when there is no compatible third party solution available. The obvious place to use a library is when one is available that a) Implements a feature that would requires weeks of work b) implements the specific feature one requires c) on the technology platform of the product d) is compatible financially and licensing wise If a,b,c and d hold then third party library is a pretty good option. Depending on the complexity of the problem one might be really lenient on c) and do whatever to integrate a MagicalPixieDustGenerator no matter how badly it fits the current tech stack. Code reuse is one of the silliest arguments ever for librarization. It's totally fine to replicate few lines of code, it's just typing. If you don't have tests to verify functionality you are screwed anyway.