The Dependency Is a Loan, and the Terms Are Theirs to Reset
When you build on another company's platform, you are not buying capability outright; you are borrowing it on terms the lender can rewrite. The app stores, the cloud APIs, the payment rails, the social graphs you integrate against — each extends you leverage today against a claim on your economics and your roadmap tomorrow. The mechanism is straightforward: the platform owner controls the interface between your product and your users, and whoever controls that interface controls the relationship. You think you own the customer; what you own is a tenancy. The rent is currently low because the platform is buying adoption. It will not stay low once the platform's growth slows and its own monetization needs sharpen.
Three Failure Modes, Each With a Different Half-Life
Platform risk does not arrive as a single event. It arrives as a family of failure modes, and the discipline is to name which one you are exposed to, because each demands a different reserve.
- Margin compression. The platform raises its take rate, deprecates the free tier, or moves a capability you depend on behind a paid plan. Slow, survivable, but it permanently resets your unit economics — and you usually cannot pass the cost through.
- Capability removal. An API is deprecated, a rate limit tightens, a data field you built a feature on disappears. Mid-speed, and it forces unplanned engineering at the platform's tempo, not yours.
- Disintermediation. The platform ships your feature as a native, default, zero-friction part of itself. Fast and often fatal, because you cannot out-integrate the integrator. This is the mode founders systematically underweight, because it looks like partnership right up until it looks like competition.
The Trade-Off Is Real, So Price It Instead of Denying It
The naive responses are equally wrong. One is to treat the platform as free infrastructure and build as if the terms were permanent. The other is to refuse all dependence and rebuild commodity capability from scratch, burning the very speed that justified the platform in the first place. The product discipline sits between them: dependence is a financeable position, and like any financed position it has a cost of capital that belongs in the model. Borrowing a platform's distribution to reach your first hundred thousand users is often the correct trade — provided you booked the dependency as a liability with a maturity date, rather than as an asset you assumed would compound forever.
Concretely, that means asking three questions before you commit a dependency, and revisiting them every planning cycle. First, how strategic is this surface to the platform's own roadmap? A capability adjacent to the platform's core business is far more likely to be absorbed than one it considers peripheral. Second, what is the switching cost we are accruing — and is it accruing to us or to them? Every proprietary call you make deepens the lock-in on your side of the ledger. Third, what does our product look like the day this dependency is withdrawn? If the answer is "we have no product," you are not running a business on the platform; you are a feature the platform has not yet decided to ship.
The Decision Implication: Own the Demand, Rent the Supply
The durable posture is an asymmetry. Rent supply-side capability freely — compute, models, payment processing, undifferentiated plumbing — because these are substitutable and the lock-in is shallow. But own the demand side relentlessly: the direct customer relationship, the proprietary data exhaust, the workflow that lives in your product rather than in the platform's. A dependency is acceptable in proportion to how easily you could replace it, and how little of your customer relationship runs through it. The product leader's job is not to avoid platform risk, which is unavoidable, but to keep it on the substitutable side of the architecture — so that when the terms reset, and they will, the renegotiation is about your cost structure and not about your existence.