FearOfReinventingTheWheel: A healthy sense of discomfort resulting from not knowing if a solution for a problem you need to solve does readily exist and the risk of wasting time and energy in the effort of solving it again from scratch.
While the fear is rational, it also need not be a dominant factor in deciding how to proceed. Choosing to re-implement some functionality is an economic, not technical, choice. When exploring the problem space, you'll find that it takes you time and energy to look at all available options. Having picked one, you then need time to learn the APIs. This might involve following a few simple tutorials, or, it might involve costly seminar attendance. Then, having learned the relevant APIs, you need to write your code to the aforelearned API. Then there is time spent debugging your code, as invariably, it will not behave as expected the first few times.
All of this investment must be gauged against the time spent just rolling your own from scratch. You'll spend time designing, coding, and debugging your implementation. If the time thus spent is less than the time spent using OffTheShelf? solutions, you should roll your own. From an organizational perspective, time is money; it takes time to both learn and write code, so therefore, the less time you spend doing either one, the more economical it is for the organization you're working in.
Rolling your own provides additional support for newcomers to your codebase as well, as if they have a question about how your proprietary framework actually works, they can review your code's unit tests, or if warranted, the actual source code itself. Usually, this proves impractical when using OffTheShelf? software; therefore, it can take newcomers much longer to get up to speed on such software.