There's a particular kind of founder I meet at conferences. They're smart. They move fast. They've found a platform with generous APIs, free distribution, and explosive growth potential. They tell me they are "riding the wave."
Eighteen months later, I often see them again. The API pricing tripled. The algorithm changed. The platform launched a competing feature. The wave, it turns out, was a riptide.
This isn't bad luck. It's a pattern, one that has repeated across Google, Facebook, Apple, LinkedIn, and now AI. And the reason founders keep falling for it isn't ignorance. It's psychology.
The platforms aren't just running a business playbook. They're exploiting the very cognitive biases that make founders successful in the first place.
The Playbook You're Already Inside
If you're building on a major platform today, you're likely somewhere in a five-stage cycle that has played out dozens of times before.
Stage 1: Identify. The platform establishes a structural advantage, a moat. Google had the index. Facebook had the social graph. OpenAI has the most capable models and the largest user base for consumer AI.
Stage 2: Open. The platform courts developers with generous terms. Free APIs. Viral distribution. Co-marketing. Partnership announcements. It feels like mutual benefit. It is mutual benefit, for now.
Stage 3: Grow. Third parties flood in, creating content, workflows, and integrations. The platform grows stronger. Its moat deepens. Critically, it now has data on what works, which features users love, which startups are gaining traction.
Stage 4: Close. The rules change. API access gets restricted. Pricing increases. Algorithmic reach declines. Features that once required third parties are now built in-house. The startup that validated the market becomes the market research.
Stage 5: Tax. The platform monetizes aggressively. If you've built your distribution on their rails, you pay, through fees, ads, or simply diminished access. The 30% app store cut. The pay-to-play algorithm. The enterprise tier that costs ten times what you budgeted.
The timeline is compressing. Google took over a decade. Facebook took five years. LinkedIn took three. In AI, these cycles may complete in months.
You've probably heard versions of this before. So why do founders keep walking into it?
The Cognitive Traps
The platform playbook works because it's perfectly designed, whether intentionally or not, to exploit how founders think.
Hyperbolic Discounting: The Free API Problem
Humans systematically overvalue immediate rewards relative to future costs. When an AI platform offers free API credits, instant distribution, and a working prototype in a weekend, the future risks feel abstract. The present benefits are tangible.
This is hyperbolic discounting: we discount the future hyperbolically rather than rationally. A founder knows intellectually that API pricing could change. But that knowledge competes against the dopamine of rapid progress happening right now.
The platforms don't need to deceive you. They just need to give you something valuable today while the costs remain theoretical.
The corrective: Force yourself to calculate the concrete number. If this API's price doubles, what happens to your unit economics? If access gets restricted, how long could you survive? Make the abstract future specific and painful. Write it down. Put it in your financial model as a scenario, not a footnote.
Loss Aversion: The Sunk Cost Spiral
Once you've built on a platform for twelve months, you've accumulated code, integrations, institutional knowledge, and user expectations. Walking away means losing all of that.
Loss aversion, the finding that losses feel roughly twice as painful as equivalent gains feel good, keeps founders committed long past the point of rationality. You're not staying because the platform is your best path forward. You're staying because leaving feels like admitting a mistake.
The platforms benefit enormously from this. Every month you build, your switching costs increase. Your loss aversion compounds. The trap tightens.
The corrective: Conduct a "fresh start" thought experiment quarterly. If you were starting today, with no existing code and no sunk costs, would you choose this platform? If the answer is no, that's a signal. The code you've written is a sunk cost regardless of what you do next. The only question is what path forward has the best expected value, not what path avoids admitting past mistakes.
Normalcy Bias: "They Wouldn't Do That"
When Twitter started restricting API access, many developers genuinely didn't believe it would affect them. When Facebook crushed organic reach, pages assumed they'd be the exception. When Apple launched Screen Time, the apps it threatened assumed the rules wouldn't change.
This is normalcy bias: the assumption that because things have been a certain way, they will continue to be that way. The platform has been friendly, so the platform will remain friendly.
Normalcy bias is particularly dangerous because platform changes often happen gradually. The API doesn't disappear overnight. It gets rate-limited. Then the rate limits tighten. Then certain endpoints become premium. Then premium becomes enterprise-only. Each individual change feels manageable. The aggregate change is devastating.
The corrective: Study history. Not abstractly, specifically. Read the post-mortems of Zynga, of Yelp's Google dependence, of the Instagram apps that got shut down. These aren't cautionary tales from a different era. They're your future, playing out on a faster timeline. The founders of those companies weren't naive. They were exactly as smart as you, and they got caught anyway.
Optimism Bias: "We're Different"
Even founders who understand the playbook often believe they'll navigate it successfully. They have a unique relationship with the platform. They're building something the platform needs. They're too small to be a threat. They're too big to be abandoned.
This is optimism bias: the systematic tendency to overestimate the probability of positive outcomes and underestimate negative ones. It's the same bias that makes people underestimate their chance of divorce while overestimating their chance of professional success.
In the platform context, optimism bias is lethally combined with survivorship bias. You've seen the startups that thrived on platforms. You haven't seen the graveyards of companies that didn't, because the dead don't write blog posts.
The corrective: Talk to founders who got burned. Not the success stories, the failures. Ask them what signals they missed. Ask them at what point they should have diversified. Their hindsight can become your foresight.
Social Proof: The Herd in the Trap
When you see hundreds of startups building on a platform, it feels validating. If everyone is doing it, the platform must be a good bet. The API documentation is full of case studies. The conference stages feature successful integrations. The message is clear: this is where smart people build.
This is social proof, and it's not wrong exactly, it's just incomplete. Social proof tells you where the opportunity is today. It tells you nothing about where the risk is tomorrow. In fact, the more startups pile onto a platform, the more attractive it becomes for the platform to extract value from that ecosystem.
The corrective: Recognize that social proof is a lagging indicator. By the time a platform is crowded with startups, you're likely in Stage 3 (Grow) or later. The question isn't whether the platform is popular. It's whether you're building a position that survives Stage 4.
The Survival Framework
Understanding the psychology isn't enough. You need structural defenses.
Build the Moat They Can't Copy
Platforms commoditize everything that touches their API. If your value is "we call the AI and display the results nicely," you will be absorbed.
What can't be copied? Proprietary data that accumulates through usage. Workflow integrations that become organizational habits. Network effects where your users create value for each other. Brand trust in a specific domain. Regulatory expertise or compliance infrastructure.
Granola, an AI meeting notes company, exemplifies this. Yes, they use AI transcription, but any platform could offer that. Their moat is the accumulated context of your meetings over time, the integrations with your specific tools, the organizational workflows built around their product. OpenAI could launch meeting notes tomorrow. They couldn't launch your meeting notes history.
Diversify Before You Need To
The time to reduce platform dependence is when you don't feel dependent. Once the platform starts tightening, you're negotiating from weakness.
This means investing in multiple channels before any single channel becomes critical. It means maintaining the ability to switch AI providers even when your current provider is cheapest. It means building direct relationships with users rather than renting access through an algorithm.
The behavioral challenge here is significant. Diversification has immediate costs and abstract future benefits, exactly the structure that hyperbolic discounting handles poorly. You have to treat diversification as insurance: a cost you pay when you don't need it, precisely so it's there when you do.
Architect for Portability
Technical lock-in multiplies switching costs, which multiplies loss aversion, which keeps you trapped longer than you should stay.
Build abstraction layers. Keep your core logic separate from platform-specific integrations. Make it possible to swap the underlying AI provider without rewriting your application. This isn't just good engineering; it's psychological protection against your future self's sunk cost fallacy.
Set Tripwires in Advance
The boiling frog problem, gradual changes that don't trigger action until it's too late, requires predetermined tripwires.
Define, in advance, the conditions under which you will begin diversifying. If API costs exceed X% of revenue. If rate limits drop below Y. If the platform launches a competing feature within Z months. Write these down. Share them with your co-founder or board. Make them concrete commitments rather than vague intentions.
The behavioral logic: you're making the decision now, when you can think clearly, rather than later, when loss aversion and normalcy bias will cloud your judgment.
Create Asymmetric Relationships
The ideal platform relationship is one where the platform needs you more than you need them. This is hard, platforms are typically much larger, but it's not impossible.
You might own a critical wedge: a specific user segment, a specific use case, a specific integration that the platform can't easily replicate. You might have distribution they want access to. You might provide data or feedback that improves their product.
The goal is to make the cost of losing you higher than the benefit of absorbing you. This doesn't guarantee safety, but it shifts the calculus.
The Uncomfortable Truth
I want to be honest about something: there's no way to entirely avoid platform risk if you're building in the current AI ecosystem.
The major AI platforms have genuine advantages. Their models are better. Their distribution is broader. Their capital is deeper. For many startups, using these platforms isn't a mistake, it's the only viable path to building something meaningful on a startup timeline.
The goal isn't to avoid platforms entirely. It's to use them strategically while building defensible value that survives their inevitable evolution.
The founders who navigate this successfully share a common trait: they're paranoid early. They assume the platform will eventually act in its own interest, because it will. They build as if the gates will close, because they will. They treat the current moment of openness as a window rather than a permanent state.
The window is open right now. It won't be open forever.
What are you building that will matter when it closes?
The author advises startups on growth strategy and platform dynamics. He has watched this playbook execute across three technology cycles and remains cautiously optimistic that the next generation of founders will learn faster than the platforms evolve. He is not holding his breath.
