Build Into the Platform, Not Away From It
Direct ecosystem activity toward strengthening the shared product and network
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 96%
Costolo distinguished between third parties building on Twitter in ways that strengthened Twitter and third parties taking Twitter’s cleaned content and audience into independently controlled clients. The latter arrangement left Twitter paying for infrastructure, spam control, and support while another company controlled the user experience and monetization. His preferred platform model allowed developers to add functionality inside Twitter, creating reciprocal value and stronger network effects. The method is to classify ecosystem activity by where users, control, and economic value accumulate; restrict extractive patterns that make the core business unsustainable; and invest in integrations that enhance the common product. It also requires candid communication, because vague transitional rules create confusion without avoiding opposition.
Origin
Dick Costolo explained Twitter’s shift away from unrestricted third-party clients and toward concepts such as Twitter Cards.
Core principles
- 01A platform should strengthen the shared network
- 02Participants must create value for both themselves and the platform
- 03Control of the user experience matters when monetization funds the service
- 04API growth is not automatically healthy ecosystem growth
How to run it
- 1
Map Ecosystem Value Flows
Document who supplies content, infrastructure, user support, distribution, customer ownership, and monetization in every integration pattern.
Pro tip Track control and economics, not just API call volume.
Watch out Rapid developer adoption can hide an extractive relationship.
- 2
Classify Integration Patterns
Separate integrations that enrich the shared product from those that replicate it and move users elsewhere.
Pro tip Ask where network effects become stronger after each interaction.
Watch out Do not label all third-party innovation harmful merely because it is external.
- 3
Define the Sustainable Boundary
Specify which capabilities remain open, which require partnership terms, and which conflict with the platform’s business.
Pro tip Tie every restriction to an understandable product or economic requirement.
Watch out Ambiguous boundaries make developers invest against assumptions that may later be invalidated.
- 4
Create Build-In Opportunities
Offer components, cards, extensions, or workflows that let developers contribute value inside the core experience.
Pro tip Make the preferred path more attractive than extraction.
Watch out Restrictions without a productive alternative can destroy ecosystem value.
- 5
Communicate Directly
Explain what is changing, why sustainability requires it, and what developers can build next.
Pro tip Use simple language even when the decision will be unpopular.
Watch out Tiptoeing around the rationale usually creates more distrust, not less.
In the wild
Third-party clients could take Twitter’s cleaned feed, own the user relationship, and place their own monetization around it. Costolo instead wanted developers to build experiences into Twitter through mechanisms such as Twitter Cards, although that vision never fully materialized as intended.
→ Twitter moved toward owning its user experience and protecting the economics needed to operate the service.
A marketplace allows developers to add inventory-analysis panels inside seller accounts but prevents them from cloning the entire marketplace experience and redirecting transactions to an external checkout.
→ Developers gain useful opportunities while transactions and network effects continue strengthening the shared marketplace.
Common mistakes
Treating API Usage as the Goal
High usage is counterproductive if developers use the API to move customers and monetization away from the platform.
Restricting Without an Alternative
A platform should offer credible ways for developers to create value inside the product rather than merely closing access.
Softening the Message Into Confusion
Trying not to upset affected developers can produce convoluted rules while leaving the underlying decision unchanged.
Is it for you?
Best for
It is best for API-driven products deciding which third-party experiences to encourage or restrict.
Not ideal for
It is not ideal for open protocols whose explicit mission is decentralized ownership and unrestricted portability.
From the transcript
“I wanted to have a platform in which third parties built into Twitter instead of taking our stuff and building away from Twitter.”
“That's a real platform, and that's where you get network effects.”
“communicating by trying to not upset people is stupid.”
From the episode
Twitter (with Dick Costolo)
Dick Costolo