Platform Dependency Is Business Model Risk: A Practical Map

Platform Dependency Is Business Model Risk

A platform dependency becomes business model risk when another company can change your price, access, capacity, quality, distribution, data rights, product parity, or strategic options faster than you can adapt.

The answer is not to eliminate every dependency. That is impossible. The answer is to map the control point, estimate the time and cost of failure, test a real alternative, and decide consciously which exposure the business will accept.

flowchart TD
    A["Customer value proposition"] --> B["Required external capability"]
    B --> C["Provider control point"]
    C --> D["Product and financial exposure"]
    D --> E["Time to detect and adapt"]
    E --> F["Mitigate, transfer, integrate, or accept"]
    F --> G["Monitor trigger and retest"]

Start with the customer result

A dependency inventory can become a list of vendors that says little about strategy.

Start with the customer result the company promises. Identify the activities and actors required to produce it. Then mark which of those activities the company does not control.

Ron Adner's ecosystem-as-structure framework defines an ecosystem around the alignment of actors and activities required for a value proposition. That is useful here because the risk is not simply that a vendor exists. It is that a change in one relationship can prevent the promised result.

An AI writing product may depend on a model API, cloud capacity, identity provider, payment processor, browser extension store, data source, and search distribution. A failure in any one can affect a different part of the customer experience.

The map should show the chain, not only the invoice.

Identify the control point

The provider may control more than uptime.

One provider can hold several control points. A model company can supply the core capability, compete in the application layer, and influence a possible acquisition. A marketplace can distribute the app, collect payments, and set product-policy boundaries.

Connect technical dependency to economics

Technical teams often record latency, error rate, and failover. The board sees gross margin, concentration, retention, and cash.

Join those views.

For price exposure, model how a ten, twenty-five, and fifty percent unit-cost change affects gross margin by customer segment. Include committed customer pricing and the time needed to reprice.

For access exposure, estimate revenue at risk during one day, one week, and one month without the provider. Include support, refunds, service credits, sales impact, and customer migration.

For switching exposure, count engineering work, evaluation, data conversion, security review, contract negotiation, customer communication, retraining, and performance loss. "We could use another model" is not a costed plan.

For strategic exposure, ask whether the provider can make the product easier to copy, harder to distribute, or less attractive to another buyer.

Measure concentration at the point of value

Spend concentration can mislead. The cheapest provider may be the most critical.

A startup might spend little on an identity service while every customer session depends on it. It may spend heavily on cloud infrastructure that can move over six months, while a smaller proprietary data feed has no substitute.

Score the dependency with factors that reflect the product:

Do not turn the score into false precision. Use it to expose disagreement and choose which test to fund.

Portability must work at an acceptable cost

The NIST Cloud Computing Standards Roadmap describes portability as moving data or applications between cloud systems at acceptable cost, and interoperability as systems working together through common specifications.

That last phrase matters. A technically possible migration that takes nine months, loses important behavior, or doubles cost may not be a viable response to a thirty-day provider change.

Portability has layers. Data export does not guarantee application portability. An abstraction layer does not guarantee equivalent model quality. A second provider contract does not guarantee capacity during a market-wide outage.

Test the layer that protects the customer promise.

Run a timed switching exercise

Choose one critical provider and define a scenario. The provider raises price by thirty percent, removes a feature in sixty days, suspends the account, suffers a regional outage, or launches a competing bundle.

Give the team the same time pressure the scenario would create. Route a representative workload through the alternative. Measure quality, latency, cost, security controls, data movement, operational effort, and customer-visible difference.

Record which steps required undocumented knowledge, privileged access, a vendor response, or a manual workaround. Those are dependencies inside the dependency.

The exercise can stop before production if safety requires it. It still needs evidence stronger than a vendor comparison table.

Choose a response that matches the exposure

Redundancy keeps a second path available. It is useful for reliability and bargaining power when the paths are genuinely independent.

Abstraction separates product logic from a provider interface. It reduces integration cost but can hide unique provider capabilities or settle on the lowest common denominator.

Contracting can add notice, capacity, price, data-export, audit, continuity, assignment, and change-of-control rights. Contract strength depends on scope, leverage, remedies, and practical enforcement.

Vertical integration brings a capability in-house. It can improve control and differentiation while increasing capital, talent, maintenance, safety, and opportunity cost.

Business-model adaptation changes pricing, customer segment, feature scope, or the share of value created elsewhere. Sometimes the right response to an expensive dependency is not a technical migration.

Acceptance is also a decision. A young company may rationally depend on one platform because speed matters more than redundancy. Record the reason, trigger, owner, and review date so temporary concentration does not become invisible permanence.

Protect differentiation outside the dependency

If the upstream provider can offer the same basic capability, the startup needs value the provider does not automatically receive.

That value may come from workflow integration, proprietary and lawfully controlled data, evaluation, customer trust, domain expertise, distribution, service, compliance operations, or a feedback loop tied to real work.

Do not claim a thin interface is a moat. Do not assume proprietary data is defensible if the company lacks rights, quality, consent, or a way to turn it into a better outcome.

Ask which customer problem would remain difficult if every competitor received the same upstream model tomorrow.

Include transaction options in the map

Dependencies can affect financing and acquisitions.

A contract may restrict assignment, require consent, terminate after a change of control, or give the provider rights that another buyer considers unacceptable. A provider that is also a competitor, investor, or possible buyer can occupy several positions in the company's strategic map.

Review these clauses with qualified counsel before a transaction creates urgency. The purpose is not to assume a provider will obstruct a deal. It is to know which approvals, rights, or migrations could shape the option set.

The Windsurf episode raised this issue because reporting connected model access, Microsoft, OpenAI, Google, and a later Cognition acquisition. The reviewed record does not prove that platform dependency caused the outcome. The [[Windsurf's OpenAI, Google, and Cognition Timeline]] keeps that causal boundary visible.

Treat supplier due diligence as an operating process

NIST's Cybersecurity Supply Chain Risk Management project frames supply-chain work as identifying, assessing, and mitigating risks across interconnected technology suppliers.

Its July 2026 ICT supplier due-diligence guide emphasizes provenance, resilience, foundational cyber practices, supply-chain tiers, and ownership or control. The guidance focuses on cybersecurity and public-sector use. Its inventory and resilience questions remain useful when adapted carefully to a commercial product.

Review the dependency when the provider changes price, ownership, terms, architecture, product scope, model behavior, security posture, data practice, or support. Review it when your company enters a new regulated market, concentrates more revenue, or approaches financing or acquisition.

Use a one-page dependency record

Complete the record for one provider before building a company-wide register. A real test of the largest exposure will teach more than a polished inventory of every vendor.

Platform dependency is not evidence that the business is weak. Unexamined dependency is evidence that part of the business model lives outside the company's decision process.

This guide is a Venture Step synthesis informed by E077, strategy research, NIST cloud and supply-chain materials, and company records reviewed on July 27, 2026. It is not legal, security, investment, procurement, or transaction advice. AI assistance was used for research organization, drafting, and validation. Publication remains unauthorized.