A 40-engineer SaaS product has a context diagram with six external systems on it. Roughly how many outbound dependencies does a product that size actually have, how would you count them without guessing, and what does the real number change?

The assumptions, stated

Start from how dependencies arrive. A team of 40 engineers ships four to six services, each of which needs identity, email or SMS delivery, payments, object storage, a search or analytics service, a feature-flag service, an error tracker, a metrics backend, and whatever the product domain requires. Add the things nobody drew because they came with the platform: the CI provider, the secret store, the DNS provider, the CDN, the package registries.

The arithmetic

Assume 5 services, roughly 4 domain-specific third parties each with heavy overlap, plus about 10 platform-wide services, plus 3 to 6 internal systems in other teams. Overlap collapses the first term to maybe 12 distinct vendors rather than 20.

• 12 domain and product vendors
• 10 platform and developer-tooling services
• 5 internal systems owned elsewhere

That is roughly 25 to 30, with a plausible range of 20 to 60 for a product of this size. Six is not a low estimate; it is a different kind of object. Six is the list somebody could recall in a meeting.

Where the count comes from, in order of completeness

1. The accounts-payable ledger. Every paid dependency has an invoice, because nobody integrates a commercial service without a contract. This is the most complete single register in the company and almost no architect reads it.
2. The egress allow-list or forward proxy log. Distinct external hostnames contacted in the last 30 days, grouped by second-level domain. This catches free and trial services the ledger misses.
3. The identity and credential store. API keys, OAuth clients and service accounts issued to third parties, which catches inbound integrations the other two miss.
4. DNS resolver logs, as the backstop for anything reached without going through the proxy.

Reconcile the four lists. The differences are the interesting part: a vendor on the ledger with no traffic is money being spent on nothing, and traffic with no invoice is a dependency nobody approved.

What the number rules in and out

The count is not the point; the classification is. Sort the reconciled list by one question: if this is unavailable for an hour, does user-visible behaviour change? Typically 5 to 8 answer yes. Those belong on the context diagram, with the direction of the call and what happens when it fails. The rest belong in a register, not a picture, because a diagram with 30 boxes is read by nobody and a register with 30 rows is read by procurement, security and whoever is on call.

The number also changes three artefacts immediately: the incident dependency checklist, the vendor concentration view (three of your critical dependencies resolving to the same underlying provider is a correlated failure you have not priced), and the exit-cost conversation.

When this is the wrong answer

A single-service product with four engineers does not need this exercise; the team can name its dependencies correctly from memory and the reconciliation costs a day for no new information. The exercise earns its cost when the organisation is large enough that no one person has seen the whole egress path, which is usually somewhere past two teams.

Common weak answers

• "Ask each team to list their dependencies." This reproduces the recall problem across more people. Self-reported inventories systematically miss platform-supplied dependencies, because the team never chose them.
• "Scan the code for HTTP clients." Finds libraries, misses configuration, and misses everything reached through a shared gateway or SDK.
• "Put all 30 on the diagram for completeness." The diagram stops being read, which costs you the six that mattered.