Add a library when the problem is hard to get right, such as cryptography, parsing or authentication. Write the code yourself when it is a few lines, stable, and easy to test. Every dependency is code you did not write but still ship, so the question is cost of ownership, not convenience.
What "build or adopt" really compares
Adopting a library trades writing time for review time, update time and exposure to someone else's mistakes. Writing your own trades review and update time for your own bugs. Neither is free.
The OpenSSF Scorecard documentation makes a point worth borrowing. It notes that some software, "especially smaller utility functions," does not normally need to be maintained, and gives the example of a library that checks whether an integer is even. A tiny, finished utility is a different risk from a large, active framework. Treat them differently.
A quick decision table
| Question | Lean toward your own code | Lean toward a library |
|---|---|---|
| How many lines would it take? | Under a few dozen, easy to read | Hundreds or more, many edge cases |
| Is it a security-sensitive domain? | No | Yes: crypto, auth, parsing untrusted input, serialization |
| Does the spec change often? | No | Yes: formats, protocols, time zones |
| Can you test it fully? | Yes, with a handful of cases | No, the input space is large |
| Could you swap it later? | Not relevant | Only if you can wrap it (see the exit plan post) |
If most answers sit in one column, the decision is easy. Mixed answers mean you should run a short evaluation before committing.
Steps to decide in about an hour
- Write down the exact behavior you need in two or three sentences. Libraries tend to offer far more than you use.
- Estimate the size of a minimal in-house version. If it fits on one screen and has an obvious test, write it.
- If a library looks right, list what it pulls in. A library that adds dozens of transitive packages for one function is a poor trade. See direct versus transitive dependencies.
- Check license, maintenance and security signals using a checklist. Our third-party library selection checklist covers this.
- Record the decision and the reason in the pull request or a short decision note, so the next person does not reopen it.
Where writing it yourself backfires
Do not hand-roll cryptographic primitives, password hashing, or parsers for hostile input. These are the places where subtle bugs become vulnerabilities, and where mature, reviewed libraries earn their place. For a deeper take on that category, see the cryptographic library selection guide.
Also avoid copying code from forums into your repository. It carries the same unreviewed risk as a library, with no version number, no advisory feed and no way for a scanner to flag it later.
Where adopting backfires
Pulling in a package for a one-line helper invites update churn and supply chain exposure for little gain. Each package is a place where a maintainer account, a build pipeline or a new release can introduce problems into your build.
Safeguard can help once you have chosen: SBOM and dependency scanning list what you actually ship, and reachability analysis shows which vulnerable code your application really calls. You can run a free scan at gold.safeguard.sh/scan.
Quick check
Is it ever fine to copy a small function from the internet?
Only if you read it, understand it, check its license, and put it under your own tests. Treat it as code you now own, because no scanner will track it for you.
Does fewer dependencies always mean more secure?
No. Fewer dependencies reduce exposure, but replacing a well-reviewed library with homegrown code in a risky domain can make things worse.
Sources
Last reviewed: 19 October 2026.
