I look at dependencies the way you’d look at hiring decisions.
Every package you bring in is another team member. It needs care. It breaks. It demands updates. It conflicts with others.
Last month, we shipped a feature with vanilla JavaScript and a touch of jQuery. Nothing else. No npm install. No build pipeline bloat.
Since then? Zero maintenance tickets related to security patches. No surprise deployments because some nested dependency got flagged. No wrestling with breaking changes in a minor version update that wasn’t supposed to break anything.
The feature just works.
Here’s what most teams miss: every dependency is a bet. You’re betting that the maintainer will keep caring. That they’ll fix bugs faster than they introduce new ones. That their priorities will align with yours when something needs attention.
Most of those bets lose.
I’m not saying never use libraries. I’m saying be honest about the cost. That date picker library that saves you two days now might cost you two weeks over the next three years. The animation framework that looks beautiful in demos might become the reason your builds randomly fail.
Lean code isn’t about being clever or purist. It’s about respecting your future self.
When something goes wrong, and it will, do you want to debug your own 200 lines of code? Or trace through 47 dependencies, three of which haven’t been updated since 2019?
The math is simple. Fewer dependencies mean fewer surprises. Fewer surprises mean your team spends time building instead of firefighting.
Your users don’t care about your package.json file. They care that the button works. That the page loads. That nothing breaks when they need it most.
Sometimes the most sophisticated technical decision is choosing to keep things simple.
What’s one dependency you’ve removed that made your life easier?
Leave a Reply