We’ve all been there. You’re working on a feature, and you need to parse some weirdly formatted date or handle a complex file upload. Your first instinct? npm install or bundle add.

It feels like winning. Someone else already solved this problem! Why should I reinvent the wheel?

The “Free” Wheel

But here’s the thing: every dependency you add is a liability. It’s code you didn’t write, but code you now own. You own its bugs, its security vulnerabilities, and its breaking changes when it decides to “improve” its API.

I recently saw a project where a developer added a 2MB library just to capitalize the first letter of a string. Seriously.

The Maintenance Tax

When you add a dependency, you’re not just adding code; you’re adding a maintenance tax.

  1. Security: Every week, there’s a new CVE. If you have 200 dependencies, you’re playing whack-a-mole with security patches.
  2. Updates: One library updates and suddenly it’s incompatible with another. You spend your Tuesday afternoon fixing a version mismatch instead of shipping features.
  3. Bloat: Your build time goes from 30 seconds to 3 minutes. Your feedback loop (remember this post?) starts to crumble.

The Rule of Three

Before I add a new gem or package, I ask myself:

  • Can I write this in 20 lines of vanilla code?
  • Is this core to my business logic?
  • How active is the maintainer?

If I can solve it with a small helper class, I do it. It keeps the project lean, the build fast, and my mental model clear.

Don’t be afraid to write code. It’s what we’re paid for.