Estimate exit cost by counting how many places call the dependency, which data formats or behaviors only it provides, and how long a replacement would take to test. Do it before adoption and again each year. The number is a roadmap input, not a precise forecast.
Why exit cost matters for the roadmap
Every dependency can become a problem later: the maintainer leaves, the license changes, a vulnerability goes unfixed, or the project is archived. The OpenSSF guide on evaluating open source software says plainly that every new dependency increases the attack surface, and it also asks you to check whether existing components can already do the job. Exit cost is the other half of that question. It tells you how painful the day will be when the answer changes.
A four part worksheet
| Factor | What to measure | Low cost sign | High cost sign |
|---|---|---|---|
| Surface | Number of files and services that import it | A handful, behind one module | Hundreds, spread everywhere |
| Data | Formats it writes that other systems read | Standard, documented formats | Proprietary storage or wire formats |
| Behavior | Quirks your code depends on | Only documented behavior | Undocumented side effects |
| Substitutes | Credible alternatives that exist | Several with similar interfaces | None, or only a rewrite |
Score each factor low, medium, or high. Two or more highs means the dependency deserves an owner, an abstraction layer, and a yearly review.
Steps to produce the numbers
- Pull the dependency inventory for the product. A software bill of materials lists the components, their versions, and relationships, which is the starting data. NTIA describes an SBOM as a formal record of the details and supply chain relationships of the components used to build software.
- Search the code for imports and calls. A count by module is enough.
- List stored data and exported files that depend on the library's format.
- Ask the team which behaviors they would be surprised to lose.
- Name one or two alternatives, even if you never plan to switch.
Turn the score into a decision
Low scores need nothing beyond normal updates. Medium scores warrant a note in the architecture decision record. High scores justify one of three actions: wrap the dependency behind your own interface, keep a vendored copy ready, or choose a lower risk alternative before adoption.
Put it on the roadmap honestly
Planning an exit does not mean planning to leave. A one page exit sketch with a rough effort range lets a product manager answer "what if this goes away" without a scramble. It also supports conversations with customers who ask about supplier risk.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how the inventory shows direct and indirect components. The direct ones are where your exit cost sits.
Quick check
Do we need an exit plan for every package?
No. Score them quickly and write plans only for the ones with several high factors.
How often should we redo the scores?
Yearly, and whenever a maintainer, license, or security posture changes.
Safeguard's SBOM and dependency scanning can produce the inventory this worksheet starts from, and there is a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
