Platform dependency.

A platform can make a startup possible and keep it from becoming independent.

Platforms compress hard work. They supply customers, identity, payments, data, hosting, ranking, developer tools, social graphs and trust. A small team can reach a market that would otherwise require years of capital.

The danger is not use. It is allowing the platform’s revocable advantage to become the company’s only route to the customer or only way to fulfill the promise.

The sequence is:

platform advantage → rapid optimization → direct relationship atrophies → unilateral rule or product change → revenue or capability falls → migration exceeds survival time.

The causal thesis is:

Platform dependency becomes terminal when the startup’s acquisition, identity, data, economics or core capability is rented under unilateral platform discretion, and leadership deepens optimization faster than it builds a direct customer relationship and portable alternative.

This manual covers dominant ecosystem surfaces governed generally: APIs, feeds, app stores, search rankings, identity systems, marketplaces and platform-native product features. A negotiated dependency on a supplier or strategic partner is bad bedfellows. A regulator applying public law is regulatory kill. A stronger rival winning customers without controlling the startup’s access is ordinary competition or outcompeting.

Platform rules can be contractual and still unilateral in practice. App stores, for example, publish review guidelines and retain wide discretion over what they accept and how they interpret quality, safety and business-model rules ^[8]. Technical access is not a property right.

The operating objective is not independence from every platform. That would destroy useful leverage. It is to know which part of the customer promise is rented, align exposure with the strength of the right and maintain a direct, portable route before the host’s incentives change.

## Cheap distribution hides control concentration

A feed, marketplace or search surface can produce customers at attractive cost. Management invests in the content, integration and operators that improve performance. As results compound, direct acquisition looks inefficient by comparison.

This is rational locally. It becomes dangerous when the company reports channel performance but not control.

Ten pages, seller accounts or apps on one platform are not ten independent channels. Nor are several acquisition tactics that all depend on the same ranking system. Diversification must be measured by independent control planes.

## Customer identity remains borrowed

A company may have millions of users and no durable permission to reach them. Platform login, social graph, follower relationship or in-app account can disappear or become uneconomic.

Direct relationship means more than an exported email list. It includes:

• informed consent to communicate;
• recognizable company brand;
• reason for the customer to return outside the platform;
• usable identity and account continuity;
• portable content or history;
• direct support path; and
• a product surface that retains value after migration.

If users think they are using a platform feature rather than the startup, the relationship is weak even when data can be exported.

## Policy is treated like an API specification

Engineers know an API can deprecate. Boards often treat distribution and policy as stable infrastructure because they are not expressed as code.

Platform discretion includes:

• ranking weights;
• permitted uses of data;
• API scope and rate;
• payment and fee rules;
• app review;
• advertising access;
• identity permissions;
• interoperability;
• content eligibility; and
• the platform launching a substitute feature.

The written rules are only the current boundary. The platform’s economic incentive predicts where the boundary may move.

Platforms also change through enforcement rather than publication. One category of developer may lose access while the public terms remain familiar. Review queues, rate limits, advertising eligibility and search placement can move the effective boundary account by account. The startup therefore needs both a text monitor and an operating monitor. Track rejection reasons, permission scopes, latency, reach, conversion and enforcement patterns across comparable participants. A contractual notice period provides little protection when practical distribution degrades before a formal termination.

## Success attracts envelopment

The startup may prove a valuable use case on the host’s infrastructure. The platform can then integrate the capability, prefer its own version, change the price of complements or restrict access needed by an external substitute.

This does not require hostility. A platform rationally optimizes ecosystem safety, user experience, revenue and strategic control. The startup must assume those incentives can diverge.

## Portability is tested too late

Teams point to data export, another cloud or a dormant web app. Migration fails because:

• users did not grant direct consent;
• exported data lacks context;
• the alternate product cannot reproduce the habit;
• identity cannot be resolved;
• customer acquisition cost changes radically;
• workflows and integrations are platform-specific; or
• migration itself violates policy.

An alternate route is real only after a representative cohort uses it and retains value.

The test must include customer action. A technically complete export that requires users to rebuild identity, relationships or workflow is not portable in commercial terms. Measure the share that consents, completes migration, recovers history and remains active after the old surface is removed. Price the support and incentive required. This exposes the difference between moving files and moving a functioning customer relationship.

## Platform relationships create false governance

Developer managers, partnership executives and joint launches improve information and can resolve issues. They do not ordinarily transfer policy authority.

Leadership mistakes access for a veto. When the platform’s company-wide incentive changes, a friendly contact may have hours of notice and no power to reverse it.

Create a platform exposure register for every surface that controls more than a material share of acquisition, revenue, identity, data or core capability.

## Map the promise

State the exact customer outcome that touches the platform:

• discovery;
• sign-in;
• payment;
• content or communication;
• data import;
• computation;
• integration;
• reputation; or
• delivery.

Spend percentage can understate risk. A free identity API can control every login.

## Classify the right

Record whether access rests on:

• negotiated contract;
• public developer terms;
• app-review approval;
• current API behavior;
• ranking convention;
• informal relationship; or
• tolerated practice.

Read termination, modification, data use, audit and notice provisions. Separate enforceable notice from customary notice.

## Model platform incentives

Ask:

• Does the startup increase platform engagement or revenue?
• Does it create safety, privacy or reputation cost?
• Does it disintermediate platform payments or data?
• Could the feature become native?
• Does platform strategy favor another format or participant?
• Is the startup large enough to matter but too small to negotiate?

Update the map from earnings calls, product launches, enforcement patterns and policy changes—not only partner conversations.

## Measure concentration

Report independent exposure dimensions:

• percent of new qualified customers;
• revenue and gross profit;
• active users whose identity is platform-bound;
• customer data available directly;
• product actions requiring the API;
• platform-specific assets and staff; and
• migration time.

Do not average them. A company can have diversified revenue but a single identity kill switch.

## Prove the escape route

Run cohorts through an alternate route. Measure discovery, consent, activation, retained behavior, data integrity, support and economics. Keep the route warm enough that the migration estimate is evidence, not hope.

## Use exposure states

• Green: rights are understood, direct relationship is strong and a representative alternate route is proved.
• Amber: concentration is material but capped, warning signals monitored and migration fits the survival clock.
• Red: the core promise or most acquisition depends on revocable access without tested portability.
• Black: a platform change is active and migration time exceeds cash or customer-retention time.

Zynga’s early growth was deeply connected to Facebook’s social graph, distribution and payments. Its 2012 annual report disclosed that Facebook accounted for a large majority of bookings and revenue and that substantially all players accessed games through Facebook ^[1]. Facebook’s own filing described the economic importance of Zynga at the time ^[3].

The relationship was not entirely informal. A filed developer addendum governed platform use and included meaningful terms affecting distribution and exclusivity ^[2].

This makes Zynga a strong concentration case and a useful survivor case.

The company had real products and large audiences. Facebook created reach and virality that would have been difficult to reproduce independently. But acquisition, identity, social context and payment economics were joined on one control plane. A platform policy, feed or strategic change could therefore affect several company systems simultaneously.

The exposure register would separate:

• revenue transacted through Facebook;
• players reachable only through Facebook identity;
• new-player discovery dependent on feed mechanics;
• game design dependent on social graph access;
• platform fees;
• contract protections and expiry;
• direct mobile and web relationship; and
• time to move a cohort.

Zynga pursued mobile and other routes over time. Diversification was difficult because portability was not merely a technical port. A game built around a platform-specific social graph must recreate identity, discovery, social context and habit.

The case does not prove that Facebook changes alone explain Zynga’s later difficulties. Game quality, portfolio decisions, competition and consumer migration mattered. It proves that the company disclosed a level of platform concentration capable of transmitting any strategic shift into several operating metrics at once.

The board should have read every apparent growth advantage together with a control discount.

## Meerkat: the social graph is removed

Meerkat used Twitter’s social graph to help users find and notify people for live video. Around its highly visible 2015 launch, Twitter restricted access. Founder Ben Rubin said the company received roughly two hours of notice, though it had understood a change was likely ^[4].

Meerkat continued operating. The team later moved toward Houseparty, and the original streaming product shut down ^[5]. The episode is therefore a platform shock followed by a pivot, not proof that one API change instantly killed the company.

The diagnostic point is exact: a socially cold-started product had borrowed its relationship map from a platform that was building a competing live-video capability. The host’s incentive to control that surface was legible.

A platform exposure register would have marked social-graph access red:

• critical to activation and distribution;
• governed by revocable access;
• platform incentive moving toward native video;
• limited notice;
• user identity only partially direct; and
• alternate graph not yet dense.

The appropriate control was not necessarily avoiding Twitter. Meerkat’s emergence may have required it. The control was treating the access as launch fuel while rapidly building direct contacts, creator-audience relationships and standalone value.

## LittleThings: an algorithm change reaches the balance sheet

LittleThings built a large digital media audience with heavy reliance on Facebook distribution. After Facebook announced feed changes emphasizing posts from friends and family, LittleThings said its organic traffic fell sharply. Reporting described the decline undermining an acquisition process and contributing to shutdown ^{[6] [7]}.

The platform change was the proximate shock, not a complete causal explanation. A business whose acquisition process and debt obligations could be broken by one feed change had accumulated structural exposure before the announcement.

The exposure register would have connected:

• share of visits and revenue originating in the feed;
• direct returning audience;
• newsletter, app and search acquisition quality;
• content economics under reduced reach;
• debt covenant sensitivity;
• buyer assumptions in the acquisition process; and
• time required to build an independent audience.

When the algorithm moved, LittleThings did not merely lose traffic. It lost a valuation premise and financial room simultaneously.

The lesson is not “algorithms change.” Everyone knows that. The lesson is to translate platform volatility into commitments. If fixed costs, debt or transaction plans assume a stable level of rented reach, exposure has already become corporate.

Maintain a platform exposure register.

## Exposure row

• customer promise;
• platform and surface;
• exact dependency;
• share of acquisition, revenue, identity, data or capability;
• governing right and modification terms;
• platform incentive;
• current warning signals;
• accountable owner; and
• review date.

## Direct-asset row

Record what the company owns:

• consented customer contact;
• independent identity;
• brand recognition;
• content and transaction history;
• usable export;
• alternate discovery;
• customer support route; and
• independent product value.

## Migration row

Name the alternate route, representative test, retained functionality, customer action required, time, cost, expected loss and policy constraints. A design mockup is not a migration path.

## Trigger row

Set actions for:

• terms or API notice;
• ranking and conversion movement;
• platform entry into the feature;
• enforcement pattern;
• partner-team reorganization;
• fee or data-access change; and
• concentration threshold.

Triggers must cap new exposure before certainty exists.

## Board dashboard

Show platform exposure beside growth rather than in an annual risk appendix. For each control plane, report the current concentration, last material policy movement, direct-customer coverage, tested migration success and days to the next irreversible commitment. Add a “platform-adjusted” view of acquisition and margin that includes fees, expected reach volatility and the cost of maintaining the alternate route.

The purpose is not to create a fictional precise discount. It is to stop leadership from comparing cheap rented growth with direct growth as though both created the same asset. One produces current traffic. The other may also produce durable consent, identity and habit.

## First 72 hours: preserve customer continuity

Confirm the exact changed surface and affected cohorts. Preserve permitted data, configuration and evidence. Stop platform-specific expansion that increases stranded assets. Communicate facts without promising reversal.

## First two weeks: separate function from route

Identify the customer outcome independent of the platform. Map which parts require identity, data, distribution, payment and habit. Test whether the product retains value without each.

Review rights and constraints with qualified counsel where necessary. Do not evade platform controls or extract prohibited data.

## Following month: earn direct permission

Offer affected users a legitimate direct relationship and portable value. Build the smallest independent route. Run a representative cohort and measure activation, retention and economics.

Reduce fixed commitments tied to old reach. Reforecast debt, hiring and acquisition assumptions under lower platform performance.

## Following quarter: govern exposure

• cap concentration by control plane;
• keep alternate routes warm;
• design identity and data portability;
• review platform incentive movement;
• price platform volatility into commitments;
• separate partner access from governance rights; and
• run migration exercises.

Repair succeeds when customers understand and value the company independently and a platform change no longer invalidates several systems at once.

1. Which customer promise depends on a platform-controlled surface?
2. What right secures access, and how can it change?
3. What does the platform gain and lose from our growth?
4. Could it absorb, restrict or deprioritize the capability?
5. How much acquisition, revenue, identity, data and functionality share one control plane?
6. Which customers can we reach with direct consent?
7. What valuable history can move?
8. Has a representative cohort used the alternate route?
9. How long does migration take relative to cash and retention?
10. Which warning signal automatically caps exposure?
11. Do fixed costs, debt or valuation assume stable rented reach?
12. Are executive relationships being mistaken for policy authority?

The board should not demand arbitrary “channel diversification.” It should demand independent control and tested portability.

The final rule:

Use platforms for leverage. Never let rented access become the only reason the customer can find, enter or receive the product.