How many dependencies is too many?

The cost arrives later and elsewhere

Adding a library is instant relief. The bill comes as upgrade work, security advisories, build weight, and the day it is abandoned by its maintainer — none of which lands in the sprint that added it.

Scale the scrutiny to the depth

A formatting helper is easy to replace and low risk. Anything touching authentication, payments, or your data model is structural, and swapping it later is a project — the same weight as choosing the stack itself.

Ask how hard it would be to remove. That answer is the real cost of adding it.

Check whether it is alive

Recent releases, more than one maintainer, and issues that get answered. An abandoned dependency at the centre of your system becomes your code, at the worst possible moment.

Beware the tiny package

Trivial packages pull in trees of transitive dependencies you never chose and cannot name. Writing ten lines yourself is frequently the cheaper long-term decision.

Wrap the ones that matter

Access anything significant through a thin module of your own, so replacing it is a contained change rather than a search-and-replace. It is exactly the interface that keeps a model swappable.

Then keep them current

Small, regular upgrades are routine; a two-year gap becomes a migration. Automated update checks plus a test suite fast enough that people run it is what makes that sustainable.