The Platform Trap: Building on Someone Else's Land

the-platform-trap Platform dependency killed Apollo, PostMyParty, and hundreds of apps when Twitter, Reddit, and Meta changed their APIs. Platform risk is existential risk. Here's how to recognize and mitigate it. platform risk, API dependency, Twitter API, Facebook API, platform lock-in, startup strategy, build vs buy, vendor dependency

According to TechCrunch, Twitter's API pricing jumped to $42,000/month. Reddit's changes would have cost Apollo $1.7 million monthly. Meta deprecated the Facebook Groups API with no warning, destroying businesses overnight. Every startup built on someone else's platform is one API change away from extinction - and founders keep falling for it.

It makes sense why this belief persists—there's a kernel of truth to it.

I've watched this cycle repeat for three decades. A platform opens its APIs, developers build businesses on top, the platform grows partly because of those businesses, and then the platform changes the rules. Sometimes it's pricing. Sometimes it's access. Sometimes the API just disappears. The developers who trusted the platform are left scrambling.

This isn't cynicism - it's pattern recognition. If your business depends on a platform you don't control, you're not building a company. You're building a feature that the platform hasn't gotten around to killing yet.

The 2023-2024 Reckoning

The last two years showed platform risk in real time. Twitter (now X) eliminated free API access and raised prices to $42,000 per month for enterprise tiers. Developers who'd built businesses on affordable API access watched their margins evaporate overnight.

Travis Fischer, who built ChatGPTbot for Twitter, had to shut down despite being willing to pay. As TechCrunch reported, the new limits - 3,000 tweets per month per account - made his tool functionally useless. Daniel Nguyen of KTool warns that X now carries "a huge risk" for makers because the platform doesn't invest in its developer community.

Reddit followed with its own API price hike. Christian Selig, developer of Apollo, calculated the new rates would cost him $1.7 million monthly. Even limiting to paid users wouldn't make the numbers work. Apollo shut down after years of successful operation.

Meta deprecated the Facebook Groups API entirely in April 2024. No warning, no migration path. Tools that had served thousands of customers for years simply stopped working. Daniel Burge of PostMyParty lost seven years of work and over 10,000 customers overnight - "a multimillion-dollar loss."

The Embrace-Extend-Extinguish Pattern

Platform behavior follows a predictable arc:

Embrace. The platform opens APIs, hosts developer conferences, celebrates the ecosystem. Third-party apps make the platform more valuable. Everyone wins.

Extend. The platform observes which third-party features users love. They take notes. Internal teams start building competitive features.

Extinguish. The platform restricts or prices out third-party access. They've absorbed the innovation; the developers are now competition. This isn't personal - it's business strategy.

As one analysis put it: "If a single API change can eliminate your business, you're not building a startup, you're building a disposable feature."

The same pattern applies to open source dependencies - you're dependent on decisions made by parties who don't answer to you. But at least open source can be forked. Platform APIs can't.

Why Founders Keep Falling For It

Knowing the pattern doesn't stop people from walking into it. The incentives are too strong:

Distribution. Platforms have users. Building on Twitter means access to Twitter's audience. Building on Facebook means access to Facebook's social graph. That distribution is real and valuable - until it isn't.

Speed to market. Platform APIs let you skip building infrastructure. You can launch faster, iterate faster, prove product-market fit faster. The dependency feels like acceleration.

Investor pressure. VCs love growth metrics. Platform access enables growth metrics. Nobody asks about platform risk until the rug gets pulled.

Optimism bias. "They won't shut down a successful ecosystem." "We have a good relationship with their developer relations team." "Our use case is different." It never is.

The Warning Signs

Platform risk isn't random. Certain patterns predict trouble:

Platform is unprofitable or under pressure. Twitter under new ownership needed revenue. Reddit needed to justify its IPO valuation. Platforms under financial stress monetize everything they can, including API access.

Your feature competes with the platform. If your app does something the platform might want to do itself, you're building their product roadmap for free. They'll thank you by copying you.

API is "free" or underpriced. Free APIs aren't sustainable. When the platform decides to price them realistically, your unit economics collapse.

Developer relations is marketing, not engineering. If the developer program exists to generate positive press rather than to enable an ecosystem, expect it to be cut when press priorities change.

Mitigation Strategies

You can't eliminate platform risk, but you can manage it:

Multi-platform from day one. If you depend on Twitter, also support Mastodon. If you depend on Facebook, also support direct email. Don't let any single platform exceed 30% of your value chain.

Own your customer relationships. Collect email addresses. Build direct channels. If the platform disappears, you need a way to reach your users.

Build defensible value. If your entire product is "X but prettier" or "Y but automated," you're one API change from zero. Build proprietary data, unique workflows, or network effects the platform can't easily replicate.

Watch the economics. If the platform is losing money on the API, price changes are coming. Model what happens to your business at 10x current costs.

Have an exit plan. Know how you'd pivot if the platform disappeared tomorrow. Some businesses have no good answer - that's worth knowing before you're in crisis.

The Data Ownership Problem

Beyond API access, platform dependency creates data problems. Your users' data lives on the platform's servers, under the platform's terms. You can't take it with you.

Researchers who built projects on Twitter's free API discovered this when over 250 public interest research projects were jeopardized by the pricing changes. Years of data collection became inaccessible. Research into disinformation, elections, and public health was halted - not because the research wasn't valuable, but because it depended on continued platform access.

This is why early architecture decisions matter so much. Building on a platform feels like a shortcut, but you're outsourcing control of your most critical asset: your data.

When Platform Dependency Makes Sense

I'm not saying never build on platforms. It makes sense when:

• The platform is the product. Shopify apps need Shopify. Salesforce integrations need Salesforce. If your value proposition is "make X better," you're platform-native by design.
• You're validating before investing. Building an MVP on someone else's distribution to test demand is smart. Just don't mistake validation for a business model.
• The platform has contractual commitments. Enterprise APIs with SLAs and deprecation policies are different from free tiers. Paid relationships come with obligations.

But for most startups building independent products, platform dependency is borrowed time. The rug pull isn't a question of if - it's when.

The Platform Alternative

The safest platforms are ones where you control the deployment:

Self-hosted infrastructure. AWS can raise prices, but they can't revoke your API access. The relationship is commercial, not permissive.

Open protocols. Email, RSS, ActivityPub - these are nobody's platform. Nobody can shut down your email integration.

Direct distribution. Your own website, your own app store presence, your own audience. Platforms can change algorithms, but they can't delete your domain.

The trade-off is growth speed. Platform distribution is faster than organic distribution. But slow growth you control is better than fast growth someone else can take away.

Score your platform risk. Check the factors that apply to your business.

Platform Dependency Scorecard

"If your business depends on a platform you don't control, you're not building a company. You're building a feature that the platform hasn't gotten around to killing yet."