How to Measure Platform Dependency Risk

How to Measure Platform Dependency Risk Before It Breaks Your Startup

Measure platform dependency by mapping every upstream input, the value it enables, who controls access and permitted use, how concentrated the dependency is, whether users can move, which substitutes are real, and how long an exit would take. Then fund at least one mitigation for the dependency that could end the company or a core journey.

The goal is not to avoid platforms. Platforms can accelerate a product. The goal is to know which acceleration also creates a veto.

Define the dependency as a user journey

"We depend on a cloud provider" is too broad. "Checkout cannot calculate tax if provider X is unavailable" is actionable.

Describe the upstream input, the user action, the business contribution, the current agreement or policy, the technical integration, stored data, downstream flow, and owner.

flowchart LR
    A["Upstream platform"] --> B["Access and permitted use"]
    B --> C["Your feature or workflow"]
    C --> D["User outcome"]
    D --> E["Revenue, retention, or mission value"]
    F["Policy, price, outage, competition, or shutdown"] --> B
    G["Substitute and exit plan"] -. "Reduces exposure" .-> C

Strava and Garmin made the dependency visible because hardware activity, API access, attribution, social value, and the shared athlete relationship all sat inside one workflow. Neither company controlled every layer.

Score control, not importance alone

A highly important provider can be manageable when access is contracted, data is portable, substitutes exist, and migration is rehearsed. A modest feature can become dangerous when the provider can revoke it immediately and no replacement can reproduce the data.

Record evidence for the score. "We have a good relationship" is not a substitute, but relationship quality can influence notice and negotiation.

Map six failure modes

Access failure covers termination, eligibility, authentication, quota, and review.

Policy failure covers a new restriction on competition, display, attribution, model training, coaching, sharing, retention, or downstream use.

Economic failure covers price, minimum spend, revenue share, data cost, and support-tier change.

Technical failure covers outage, field removal, changed semantics, webhook behavior, latency, and deprecation.

Strategic failure covers the platform launching a competing feature, prioritizing its own surface, changing distribution, or acquiring a substitute.

Trust failure covers privacy, security, safety, content, regulatory, or reputational events that make continued dependence unacceptable.

One dependency can trigger several at once.

Use current terms as evidence, not reassurance

Strava's current API agreement restricts competing and replicating uses, governs display and privacy, and permits modification or discontinuation. Garmin's current API Brand Guidelines impose source-attribution obligations across multiple output surfaces.

GitHub's breaking-change policy and Stripe's upgrade guidance show more structured version and migration practices. Those practices reduce some risks but do not remove commercial, strategic, data, or shutdown exposure.

Capture the exact version governing the product. Current web pages can change. A screenshot is not enough when the page links to separate terms, program agreements, or brand rules.

Calculate exit time honestly

Exit time begins when the organization decides to leave and ends when users can complete the critical outcome without the provider. It includes approval, implementation, migration, testing, consent, contract, support, documentation, deletion, and downstream updates.

If exit requires building a new identity system, losing history, retraining users, and replacing a network, the dependency is not a simple API swap.

Choose a mitigation that changes the exposure

A monitoring alert helps detection but not substitutability. A contract clause may improve notice but not data migration. An adapter may improve technical replacement but not permitted use.

Match mitigation to the dominant failure mode. Preserve organization-owned identifiers and user records. Add a second independent source. Create an export. Negotiate notice and transition. Narrow the dependent feature. Build a manual continuity path. Fund a substitute integration. Diversify distribution. Strengthen the direct user relationship.

An unfunded contingency is an idea. Put an owner, date, budget, evidence requirement, and test cadence beside it.

Review the register before strategy locks in

Review dependencies when entering a platform, changing a core use, crossing a concentration threshold, receiving new terms, raising capital, planning a major launch, or seeing the upstream provider move into the product category.

The register should be small enough to use and detailed enough to act.

The examples are illustrative. Use evidence from the actual product.

Dependency is not the same as a weak product

Every product depends on suppliers, infrastructure, law, and distribution. Risk becomes existential when the product does not control a critical input, cannot replace it, cannot preserve the user outcome, and has no time to adapt.

[[Is Your Product Actually a Feature]] examines whether the product owns durable value beyond one upstream capability. [[What Happens When an API Policy Changes Under Your Product]] supplies the incident procedure after a signal appears.

This page provides general strategy and product guidance, not legal or financial advice. It reflects sources reviewed on July 27, 2026. AI assistance was used for research organization, drafting, and validation. Publication remains unauthorized.