Gems I use fall into three categories.<p>A lot of my projects are just wrappers around one main gem. Rails, Nokogiri, Roo, API wrapper gems. These are &#x27;project gems&#x27;. If they give me problems, I&#x27;ll re-evaluate the scope of the project and perhaps pick another gem to orient the project around. Once the project reaches maturity, I&#x27;ll default to fixing the problem rather than re-engineering it unless the problems run deep.<p>Sometimes I&#x27;ll use gems like Phoner to handle datatypes that are too tricky to do with regular Ruby. I&#x27;ll call these &#x27;utility gems&#x27;. When I include a utility gem, generally it has one job and one job only, it&#x27;s invoked in exactly one place in the code and gets included in that file. I can generally replace a utility gem with stdlib Ruby code if I really need to.<p>I also have what I call &#x27;infrastructure gems&#x27;. These are gems like pry, capistrano, and thor that I tend to include in every project where it seems they would be useful. These are gems that are worth getting to know very well because they solve really hard problems that you don&#x27;t want to use stdlib for. If these give me problems I will do whatever I need to to resolve them and understand why the problem exists, because the costs of migrating off of them would be <i>steep</i>.<p>The decision to use a gem should not be taken too lightly, but nor should it weigh large on the mind. Be quick to try it out, but also quick to take it out.