Theme 10 — Vendors & Dependencies
The reflex this theme builds: every dependency is a decision someone else can unmake.
Why this theme matters
A modern AI system is mostly other people's systems. The model is behind someone's API (Application Programming Interface), the identity attributes come from a bureau, the compute is a cloud provider's, and the code is stitched together from hundreds of open-source packages maintained by strangers. Every one of those dependencies imports someone else's roadmap, pricing model, security posture, and failure modes straight into your production path — and none of them signed up for your uptime, your margins, or your client commitments.
The recurring root cause in this theme is asymmetric attention: the dependency matters enormously to you and not at all to them. The vendor sunsets an API version as a line item in a release plan; for you it's a production outage. A maintainer's compromised account is a bad week for an open-source project; for you it's a supply-chain incident. A pricing change is their revenue strategy; it's your architecture invalidated. The drills below train the habit of treating every dependency as a live risk with an owner, a fallback, and an exit — not as infrastructure that will simply continue to exist because you need it to. Abbreviations are expanded on first use; the full reference is ../glossary.md.
The drills
| # | Drill | One-line hook | Problem diagram | ~Difficulty |
|---|---|---|---|---|
| 59 | The Deprecation Email | Six months' written notice, delivered to an alias nobody reads — the sunset arrives as a Tuesday-morning outage. | timeline | intro |
| 60 | The Package That Turned | A compromised release auto-updates into production overnight; "are we exposed?" takes days to answer. | sequenceDiagram | core |
| 61 | The Price That 10×'d | Per-seat becomes per-API-call, and the chatty architecture is the negotiating weakness. | sequenceDiagram | core |
| 62 | The 99.9% That Didn't Matter | A full-day vendor outage, nine hours of queued applications — and a $400 service credit. | sequenceDiagram | core |
| 63 | The Acquisition | The vendor is acquired by your biggest client's competitor, and three clocks start running at once. | timeline | advanced |
Best practices — the dependency checklist
What to actually do, distilled from drills 59–63:
- Maintain a dependency registry: every external API (Application Programming Interface), data feed, model endpoint, and package — each with its version, a named owner, the contract renewal date, and its sunset status. Review it quarterly; an entry with no owner is itself a finding.
- Route all vendor communications to a monitored team channel — never a personal inbox, never a distribution alias. Test the route annually: if a fake deprecation notice sent to your own contact address reaches no human, fix that before a real one doesn't.
- Track version currency as tech debt with a dashboard: how many dependencies are on deprecated or sunset-announced versions right now should be a number, not a postmortem discovery.
- Pin every dependency with lockfiles so nothing in a production build changes without a reviewed commit. Auto-update is a convenience feature for someone else's threat model.
- Put a cooling-off window between release and adoption — let fresh package versions age for days while the ecosystem acts as your canary — and add provenance and signature scanning to CI (Continuous Integration).
- Maintain an SBOM (Software Bill of Materials — a machine-readable inventory of every component in your software) so "are we exposed to package X version Y?" is a minutes-long query, not a days-long archaeology project.
- Know your cost-per-decision for every vendor and model what a pricing-model flip would do to it. A number nobody tracks is a negotiation you've already lost.
- Design with caching and batching even when calls are free — free at the margin is a pricing decision someone else can unmake, and a chatty architecture is a pre-paid concession at your next renewal.
- Negotiate exit, portability, and data-return terms at signing, while you still have leverage: format, timeline, escrow where warranted, and deletion attestation — specifics, not "commercially reasonable efforts."
- Read every SLA (Service Level Agreement) as a refund policy, not a reliability guarantee, and design the thing the SLA doesn't give you: a fallback mode per critical dependency — cache-and-degrade, secondary source, or a queue-and-hold policy chosen by the business in daylight.
- Run vendor game days: black-hole a critical dependency in staging and watch what your system actually does. A fallback that has never engaged is a hypothesis, not a control.
- Review vendor viability and conflict-of-interest annually — ownership, funding, acquisition exposure — and rehearse the exit for critical dependencies. You don't need a second vendor live; you need to know the switch takes weeks, not quarters.
- All themes and the full curriculum: ../README.md
- Abbreviations and terms: ../glossary.md