A new dependency arrives in three minutes — npm install, restart the dev server, write the import. The cost is invisible at the moment of choice and obvious only in year three, when the maintainer has moved on, the breaking change ships, and your audit log says you were the one who added it.
We score every prospective dependency on five axes before we add it: maintainer count, age of the project, weekly downloads, breaking changes per year, and whether we could write the code ourselves in under an afternoon. The rule of thumb is straightforward: if any one of those five fails the bar, we write it ourselves.
Adding a library feels free. Owning it for the next four years does not.
The cost of writing it ourselves is one afternoon and a 40-line file with a test. The cost of taking the dependency is one afternoon now, plus one Wednesday in 2027 spent reading a migration guide, plus one weekend in 2028 spent rewriting around a deprecation. We do this exercise out loud in pull-request comments and we have rejected our own dependency proposals twice this quarter.
There is one exception: the cryptographic primitives. We will never write our own. For everything else, the question is whether your team can hold the contract for the lifetime of the system. If the answer is no, the answer is no.