What I look for before adding another dependency

Popularity is not enough

A dependency can look attractive because it solves the demo quickly. Before adding it, I look at maintenance signals, release cadence, API stability, issue quality, and how easily the project can move away from it later.

The right question is not only whether the library works today. It is whether the team will still trust the decision when the app, platform, and requirements change.

Check the operational cost

Every dependency becomes part of the product surface. It affects build time, binary size, security review, platform compatibility, and the mental model new engineers need to learn.

For small problems, boring platform APIs can be the better tradeoff. For complex domains, a mature library can save months of edge cases.

Wrap what matters

When a dependency touches core product behavior, I avoid spreading its API through the entire codebase. A narrow adapter keeps the decision reversible and makes testing more direct.

That does not mean abstracting everything. It means protecting the parts of the product that should not care which implementation is underneath.