Build, borrow or buy.

The question is never whether to use open source, only which and how.

What is in this guide

1. 01The short answerFive rules that settle most decisions on day one.
2. 02The three optionsWhat open source, proprietary and in-house actually mean, and what each really costs.
3. 03Is open source safe?The many-eyes argument, where it fails, and why home-built code is usually the bigger risk.
4. 04The trade-offs in depthCost, speed, control, lock-in, licensing, people, longevity and compliance.
5. 05A decision methodTwo questions, one matrix, and lists of what to never build, usually buy, and usually borrow.
6. 06Vetting an open-source packageA scorecard, red flags, free tools, and a licence cheat sheet.
7. 07Vetting a vendorWhat to check before your data and your uptime depend on someone else.
8. 08Building with Claude CodeThe AI-specific failure modes and the guardrails that stop them.
9. 09How the answer changes with scaleFive team-size stages, what shifts at each, and the signals that it is time to revisit a decision.
10. 10Customers, investors and regulatorsSBOMs, SOC 2, the EU Cyber Resilience Act, and licence diligence in a fundraise or sale.
11. 11Worked examplesTwelve common components with a call for today and a call at scale.
12. 12ChecklistsBefore you add a package, before you buy, before you build.

Appendices: A · glossary and B · sources.

Build what makes you different. Buy what can sink you. Borrow the rest.

For a small team that is new to coding, using well-established open source is much safer than writing your own. The danger in open source is choosing the wrong package and failing to keep it updated, not open source as a category. Code you write yourselves has the same kinds of flaws, and nobody else is reading it. A popular library like Django, Postgres or OpenSSL has had thousands of people find and fix the bugs you would otherwise write.

Proprietary software is the third option, and for a small team it is often the safest of all for the few components where a mistake is catastrophic: logins, payments, secrets and anything holding regulated data. You are paying a vendor to own the security work you cannot yet do.

Five rules that settle most decisions

1. Build only what makes your product different.

   The logic customers pay for is the one thing nobody can sell you. Everything else you build is a liability you have to maintain.

2. Never build security primitives.

   No home-made encryption, password hashing, login or session handling, or input sanitisation. These are where breaches come from.

3. Buy where failure is catastrophic and the domain is regulated.

   Payments (Stripe), authentication (Clerk, Auth0, Supabase Auth), secrets management, email delivery.

4. Borrow everything in between, carefully.

   Frameworks, utilities, UI components and data handling come from popular, maintained open-source projects that a human has checked.

5. Every new dependency is a decision a human signs off.

   Claude can propose a package; one of you verifies it exists, is the real one, and is maintained before it goes in.

Three ways to get software, and none of them is free.

Side by side

Built in-house is left out of the default column on purpose: for a team at this stage it is the right answer only for the product’s own logic.

The many-eyes argument is true for popular projects, and false for the long tail.

The case for open-source security is that anyone can read the code, so flaws get found and fixed. That holds for heavily used, well-funded projects. It breaks down in three places, and the public record shows all three.

What the record says

1. Most damage comes from not updating.

   Black Duck found 86% of audited codebases carried a known-vulnerable open-source component. The fix existed; it was not installed.

2. Supply-chain attacks target the install step.

   Typosquatted names, hijacked maintainer accounts, malicious updates and, now, hallucinated names that AI tools suggest. The defence is controlling what gets installed and when.

3. Eyes concentrate on popular projects.

   A package with millions of weekly downloads and a funded foundation is scrutinised. One with a single anonymous maintainer is not.

4. Proprietary software is not immune.

   Closed vendors have breaches too (SolarWinds, Okta, MOVEit). You simply cannot see the code, and you depend on their disclosure.

Why home-built code is usually the bigger risk

Code your team writes gets exactly two reviewers, both new to the work. Code Claude writes is fluent and confident, and it can still be wrong in ways that pass a quick read: a missing authorisation check, an injectable query, a token stored in the browser. A mature library has already met those attacks. The safe ranking for a beginner team, in security-critical areas, is managed service first, popular open source second, home-built last. In non-critical areas, popular open source comes first.

Eight trade-offs, each with the question that settles it.

1. Total cost of ownership.

   Free software is not free and paid software is not just its price. Count engineer hours for integration, updates, incidents and eventual migration.

   Settling questionWhat would one of us spend in hours per month to own this, and what is that hour worth against shipping product?

2. Speed.

   Installing beats building almost every time early on. The cost of speed shows up later as integration debt.

   Settling questionDoes shipping two weeks sooner matter more than a perfect fit?

3. Control and fit.

   In-house fits exactly; open source can be forked; proprietary fits only as far as the vendor allows.

   Settling questionWill we need behaviour this tool cannot give us within the next year?

4. Lock-in and exit.

   Every choice has an exit cost. Vendors raise prices, change terms or shut down; open-source projects relicense (HashiCorp Terraform moved to the Business Source License in 2023; Redis went source-available in 2024 before adding AGPL in 2025).

   Settling questionIf this disappeared in 90 days, how hard would leaving be?

5. Licensing and legal.

   Permissive licences are nearly frictionless. Copyleft can oblige you to publish your code. Source-available licences can bar competing uses.

   Settling questionHave we read the licence of everything that ships, including transitive dependencies?

6. People and knowledge.

   Popular tools have documentation, Stack Overflow answers and engineers you can hire who already know them, and Claude knows them well. Home-built tools exist only in your heads.

   Settling questionCould a new hire be productive with this in a week?

7. Longevity and bus factor.

   Check whether the project or vendor will outlive your need for it.

   Settling questionHow many maintainers, how much funding, how long in production?

8. Compliance.

   Customers and regulators increasingly ask what is in your software and who is responsible for it. Vendors with SOC 2 or ISO 27001 reports transfer some of that burden.

   Settling questionWill this choice appear in a security questionnaire, and can we answer it?

Five minutes of checking before every new dependency.

Free tools that do most of this for you: OpenSSF Scorecard and deps.dev (maintenance and security signals), Socket (flags malicious and suspicious packages, not just known CVEs), GitHub Dependabot (alerts and update pull requests), and npm audit or pip-audit (known vulnerabilities).

Licence cheat sheet

Check the exit before you check the features.

AI makes building cheap and judgement scarce.

Claude Code makes writing code nearly free, which makes “just build it” tempting. The cost of software was never mostly the writing. It is the owning: understanding, securing, testing and maintaining. AI lowers the first cost and leaves the others where they were, so for a beginner team it tilts the right answer further toward proven components, not away from them.

Failure modes to watch for

Add this to CLAUDE.md

## Dependencies and security

- Do not add a new dependency without listing it, explaining why the
  standard library or an existing dependency will not do, and linking
  its official repository.
- Prefer the standard library. Prefer packages we already use.
- Never implement cryptography, password hashing, authentication,
  session handling or input sanitisation. Use <our auth provider> and
  the framework's built-in protections.
- Never put secrets in code. Read them from environment variables.
- Pin exact versions. Commit the lockfile.

Guardrails to set up once

1. Lockfiles, committed.

   package-lock.json, pnpm-lock.yaml, uv.lock or poetry.lock. Builds install exactly what you tested.

2. Automated update pull requests.

   Dependabot or Renovate, with security updates on. Merge them weekly.

3. A waiting period for new releases.

   Renovate’s minimumReleaseAge (and similar settings in pnpm and uv) delays brand-new versions by a few days, which is when most hijacked releases are caught.

4. Scanning in CI.

   npm audit or pip-audit for known flaws; Socket for malicious packages; GitHub secret scanning and push protection.

5. Branch protection.

   Nothing reaches main without the other person’s review, including dependency changes.

6. Pin CI actions by commit hash.

   Not by tag, which can be moved (the tj-actions lesson).

The defaults hold; the economics and the obligations move.

The core rule (build the differentiator, buy the dangerous, borrow the rest) holds at every size. What changes is the cost of engineer time against vendor bills, the team’s ability to own complex systems safely, and how much customers and regulators demand to know. Five stages:

What drives the shift

1. The cost curve crosses.

   Vendors are cheap at small scale and can become the largest line after payroll. When a bill reaches the fully loaded cost of the engineers it would take to build and run a replacement, and the component is core or strategic, a build becomes worth costing. Count maintenance, on-call and migration, not just the initial build.

2. Capability arrives.

   A team with a dedicated platform or security engineer can safely run what a two-person team cannot: self-hosted databases, internal auth gateways, forks of upstream projects.

3. Obligations arrive.

   Enterprise customers, auditors and regulators ask for SBOMs, licence reports and vulnerability-handling processes (section 10). That pushes toward fewer, better-known dependencies and vendors with audit reports.

4. Leverage arrives.

   Larger teams can negotiate vendor contracts, sponsor maintainers, contribute fixes upstream instead of waiting for them, and influence the projects they rely on.

5. The cost of a wrong choice rises.

   Migrating a component at 200 engineers is a quarter-long project. Lock-in and licensing deserve more scrutiny the bigger you get.

Signals to revisit a decision

Customers, investors and regulators turn dependency hygiene into paperwork.

Twelve components, decided today and at scale.

Named products are common examples, not endorsements. Check current pricing and terms before choosing.

Three short checklists.

Tick items as you go. Ticks are saved in this browser only, so each person keeps their own.

Glossary

Sources

• Black Duck, Open Source Security and Risk Analysis (OSSRA) report, 2025. Summary: securitymagazine.com/articles/101420-open-source-software-vulnerabilities-found-in-86-of-codebases
• Spracklen, J. et al., “We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs,” USENIX Security 2025. arxiv.org/abs/2406.10279
• XZ Utils backdoor (CVE-2024-3094). en.wikipedia.org/wiki/XZ_Utils_backdoor
• Krebs on Security, “Self-Replicating Worm Hits 180+ Software Packages,” 16 September 2025. krebsonsecurity.com/2025/09/self-replicating-worm-hits-180-software-packages
• Wiz, “Shai-Hulud: Ongoing Package Supply Chain Worm.” wiz.io/blog/shai-hulud-npm-supply-chain-attack
• Open-source licence changes, MongoDB to Redis. softwareseni.com/the-open-source-license-change-pattern-mongodb-to-redis-timeline-2018-to-2026-and-what-comes-next
• Redis returns to open source under AGPL, May 2025. techstrong.it/data/redis-shifts-back-to-open-source
• Log4Shell (CVE-2021-44228), Heartbleed (CVE-2014-0160), left-pad (2016), event-stream (2018) and tj-actions/changed-files (CVE-2025-30066) are documented in their respective public advisories.
• Regulation (EU) 2024/2847, the Cyber Resilience Act; US Executive Order 14028, Improving the Nation’s Cybersecurity, 2021.