The real kicker here is development at scale. Anyone that comes in has to learn how all that custom code works, and chances are if you're like any startup I've interviewed/worked at (20+), you don't have any documentation on the code, or it's so out of date it's useless.
Meanwhile if you use that "off the shelf" thing and introduce a few hacks to make it work for your use cases, all I have to learn is those hacks and why they're there. The rest is already documented and maintained by another company who built this dev tool.
This is something that should be taken care of when vetting the project on whether or not the company should use it. Anyone whos been around that block a few times knows to look for:
- current dev status (hasnt been updated in 6 months? probably shouldnt touch it)
- community review (is anyone else using it, hows it working for them?)
- limitations (this one is pretty obvious, technical limitations/benchmarks/etc)
- code quality (unless its a third party service you pay for you should be able to see if the code is worth a crap pretty easily).
- vendor lock (if we need to change, how easily can we change? do they use open source protocols/standards that other tools understand?)
But this is the point. There is no good rule for when you should use a library, and when you should build your own stuff in-house. It always depends on the specifics of your situation.
You need to think about things like the quality of existing third-party solutions, and how well they will fit into your codebase. You might find a third-party library that is 90% of what you need, but there just isn't a good way to get to the other 10%, and so sometimes even in those cases it makes sense to roll your own.
Other times I see people rolling their own versions of stuff, and it's clearly much worse than readily available libraries. You just have to look at the specific situation to determine the right thing to do.
Meanwhile if you use that "off the shelf" thing and introduce a few hacks to make it work for your use cases, all I have to learn is those hacks and why they're there. The rest is already documented and maintained by another company who built this dev tool.