The "buy vs build" decision comes down to a number of factors. Can you maintain the tool that you are buying (even if it's open-source)? Is there adequate support for it, if you run into a problem? Do you have the resources to build it yourself, and are you smart enough to generalize it so it can be reused in a variety of scenarios? And so on.
Regarding dependency injection: DI containers are not needed for most applications. Unless your application is a large, enterprise-type application, you don't need a DI container, and if you do need one, there are a number of containers already available that would serve the purpose well.
Smaller applications benefit more from a simpler form of DI, like injecting your dependencies directly through the constructor methods of your objects. You would only use a DI container if you needed to provide a central place to manage your dependencies in, say, an XML file describing them.
In the vaguest of terms, there is a "rule of three." If you find yourself doing the same thing three times in a software application, you either refactor it into its own tool or method, or find an off-the-shelf tool that replaces those three things with one generalized thing. Knowing when to do this comes with experience.