09-the-api-economy-why-every-app-wants-to-be-your-operating-system

kicker: “Platform Creep” title: “The API Economy: Why Every App Wants to Be Your Operating System” subtitle: “How third-party integrations became the new lock-in strategy” description: “Every modern app ships with an API marketplace. What looks like openness is actually a land grab for your digital workflow. Here’s how platforms use integrations to become irreplaceable.” pubDate: 2027-07-09T19:00:00.000Z heroImage: /the-api-economy-why-every-app-wants-to-be-your-operating-system.avif tags:

apis
platform economics
developer tools
software integration
vendor lock-in

The Integration Tax

I opened Notion this morning to write a quick note. Before I could type a word, I saw fifteen integration suggestions: Slack, Google Drive, Figma, GitHub, Jira, Zapier, and nine others I’d never heard of. A year ago, this would have excited me. Today, it just makes me tired. Every app wants to be the center of your universe. They all promise the same thing: “Connect everything in one place.” But what they’re really building is a dependency trap. The more you integrate, the harder it is to leave. This isn’t about convenience anymore. It’s about control. And we’re all complicit. [AFFILIATE] The API economy runs on a simple principle: make your product indispensable by becoming the glue between other products. Notion doesn’t want to be a note-taking app. It wants to be your command center. Slack doesn’t want to be a chat tool. It wants to be your operating system. Airtable doesn’t want to be a spreadsheet. It wants to be your database layer for everything. The strategy is elegant. Build a decent core product, then open an API. Let developers create thousands of integrations. Wait for users to wire their entire workflow through your platform. Now you’re not competing on features anymore—you’re competing on switching costs. I’ve watched this play out at three companies. Each time, we’d adopt a new tool for one specific need. Within six months, it had tentacles in everything. We’d joke about being “locked in,” but nobody actually wanted to leave. The integration debt was too high.

How We Got Here

The API economy didn’t start with Notion or Slack. It started with Salesforce in 1999. Marc Benioff called it “platform as a service” before that term meant anything. The pitch was revolutionary: instead of building custom software, you’d customize Salesforce with apps from their marketplace. [BBC] It worked because Salesforce understood something others didn’t. The value wasn’t in the CRM features. It was in the ecosystem. Once you had fifty custom apps running on Salesforce, you weren’t switching to Microsoft Dynamics. The data model was too embedded, the workflows too specific, the training too expensive. Stripe applied this same playbook to payments. Their API was so elegant that developers didn’t just use it—they built their entire product architecture around it. When Stripe raised prices, nobody left. The integration was ten layers deep. Then came Zapier, which turned integrations into a commodity. Suddenly, every SaaS product could offer “thousands of integrations” without writing a single line of code. The barrier to platform building collapsed. By 2020, every B2B tool was playing the same game. Build a product. Ship an API. Partner with Zapier. Launch a marketplace. Hire a “Head of Ecosystem.” Write case studies about customers who integrated fifteen tools. The language changed too. “Integration” became “ecosystem.” “API access” became “platform.” “Vendor lock-in” became “deep product-market fit.”

The Architecture of Dependence

Here’s what actually happens when you integrate everything: Your CRM talks to your email tool, which talks to your calendar, which talks to your project manager, which talks to your accounting software, which talks back to your CRM. Each connection adds value. Each connection adds fragility. One company I advise runs 127 active integrations across 23 core tools. They employ two full-time engineers just to maintain the pipes. When Asana changed their API last year, it broke four downstream systems. The fix took three weeks. But they can’t consolidate. Each tool made sense in isolation. Together, they created a system nobody fully understands. The architecture diagram looks like a bowl of spaghetti drawn by a cat on catnip—specifically, a British lilac cat with particularly poor spatial reasoning.

graph TD
    A[CRM] --> B[Email Platform]
    A --> C[Project Manager]
    B --> D[Calendar]
    C --> D
    C --> E[Slack]
    E --> F[GitHub]
    F --> G[CI/CD]
    G --> H[Monitoring]
    H --> E
    A --> I[Accounting]
    I --> J[Payroll]
    J --> A
    D --> E
    B --> E
    E --> K[Document Storage]
    K --> A
    K --> C
    K --> B

This is normal now. Every company of fifty people or more has a graph like this. We call it “best-of-breed” strategy. We don’t call it what it is: technical debt disguised as flexibility. The platforms love this complexity. It makes them essential. When you have thirty tools and 127 integrations, you don’t switch tools—you might break everything.

Method: Following the Integration Trails

To understand how deep this goes, I did something tedious. I audited my own tool stack—every SaaS product I pay for, personally and through my business. Then I mapped every integration I’d enabled. The process took four hours. I found connections I’d forgotten about. A Notion-to-Google-Calendar sync that hadn’t worked in months but was still running. A Zapier workflow that duplicated Slack messages to Airtable for “analysis” I never did. An RSS-to-Email automation I’d set up in 2024 and completely forgotten. In total: forty-two enabled integrations across seventeen products. Most added no value. Some actively created problems—duplicate notifications, sync conflicts, stale data. But I couldn’t turn them off without checking what else might break. That checking process revealed more connections. My email tool fed my CRM, which fed my accounting software, which fed my project tracker, which fed Slack, which fed my calendar, which fed my email tool. It’s circular. By design. I interviewed eight SaaS founders about their integration strategy. Seven said some version of: “Integrations drive retention.” One was more honest: “It’s a moat. Once they’ve built workflows on our API, they’re not leaving.” The honest founder requested anonymity. The others were happy to go on record. The difference tells you everything.

The Marketplace Illusion

Every platform’s marketplace looks the same. Hundreds of app tiles with cheerful icons. Category filters: “Productivity,” “Analytics,” “Communication,” “Sales.” Featured apps at the top—always the same ones. Zapier shows up on every marketplace. So does Slack. So does Google Workspace. It’s the integration equivalent of finding the same chains in every airport terminal. The economics explain why. These mega-integrations drive user acquisition for smaller platforms. If you can say “integrates with Slack,” you inherit Slack’s credibility. The smaller platform pays for this in referral fees and data access, but it’s worth it. For users, the marketplace creates false confidence. “Look at all these integrations—this platform must be legitimate.” We don’t ask whether we need these integrations. We just feel reassured they exist. I tested this by picking three random B2B tools I’d never used. Each one advertised “1000+ integrations.” I signed up for trials and checked their actual marketplace. Tool A: 1,247 listed integrations. The first fifty were legitimate apps I recognized. The next fifty were tools I’d never heard of. After that, it was long-tail obscurity—integrations with platforms that maybe ten people worldwide use. Tool B: 2,103 integrations. But 1,800 came through Zapier. They were counting every Zapier connection as a separate integration. Technically true, marketing-wise misleading. Tool C: 890 integrations, but forty-three were deprecated. Another sixty had “beta” tags that had been there for three years. The company was inflating their count by keeping dead integrations listed. The numbers are vanity metrics. But they work. We see “2000+ integrations” and think “mature platform.” We don’t audit the list.

The Real Cost

[AFFILIATE] Integration debt compounds like technical debt, but it’s harder to see. There’s no linter warning you about tight coupling. There’s no test suite for workflow fragility. You only discover the problem when something breaks. And things break constantly. APIs change. Authentication methods evolve. Rate limits tighten. Services shut down. Each change ripples through your integration graph. Last month, Twilio deprecated a webhook endpoint. Sixteen of my automations stopped working. I didn’t notice for five days because the failures were silent. When I finally investigated, I found a backlog of 342 missed notifications. This happens all the time, to everyone. We’ve normalized unreliable infrastructure. “Oh, the Slack integration is acting up again.” “Just rebuild the Zapier workflow.” “Clear the cache and reconnect your account.” Nobody calculates the actual cost. The engineering time to maintain integrations. The support tickets when things break. The lost productivity from dealing with sync errors. The meetings to troubleshoot why data doesn’t match across systems. One study from a DevOps consultancy put the annual cost at $78,000 per company for a typical fifty-person startup. That’s one junior engineer’s salary, spent entirely on keeping the pipes connected. For enterprises, it’s worse. They run integration platforms—MuleSoft, Workato, Tray.io—that are themselves complex products requiring dedicated teams. Some companies employ integration architects whose entire job is managing the graph.

Why Platforms Push Integration

[BBC] The business model depends on stickiness. SaaS companies live and die by retention. Acquisition is expensive; keeping customers is cheaper. Integrations are retention insurance. Consider the unit economics. A typical B2B SaaS customer costs $1,200 to acquire (marketing, sales, onboarding). They pay $1,000 per year. The company makes money in year two, if the customer renews. Without integrations, annual churn might be 25%. With deep integrations, churn drops to 8%. That difference compounds over time. After five years, the integrated cohort is worth 3.4x more. Platform teams know this. They measure “integration depth” as a retention metric. The more integrations you enable, the less likely you are to churn. Some companies trigger automated check-ins when integration usage drops. The incentives are clear: get users to integrate as much as possible, as quickly as possible. That’s why every onboarding flow now includes an integration setup step. That’s why they email you integration suggestions. That’s why they gamify it with “setup completion” progress bars. It’s not about making your workflow better. It’s about making it harder to leave.

The Developer Experience Trap

APIs are marketed to developers as empowerment. “Build whatever you want on our platform.” But API access is actually about data access. The platform wants your data as much as you want their functionality. Read the API terms of service. Most platforms reserve the right to analyze usage patterns, aggregate anonymized data, and use insights to improve their product. Translation: they’re watching what you build and learning from it. Some platforms go further. Their API terms explicitly allow them to build competing features. If you create a popular integration, they might just absorb it into the core product. They call this “listening to the ecosystem.” Zapier faced this when several of their integration partners built native versions of popular Zaps. The partners argued they were just responding to user demand. Zapier argued it was platform exploitation. Both were right. This creates a prisoner’s dilemma for developers. Build on the platform and risk getting copied, or avoid the platform and miss the distribution. Most choose to build. The platform wins either way.

The Interoperability Myth

Open APIs sound like interoperability. They’re not. Every platform has its own data model, authentication scheme, rate limits, and quirks. Connecting two platforms requires translation layers, not just API calls. That’s why integration platforms exist. Zapier makes money by handling the translation. They absorb the complexity of 6,000+ different APIs so you don’t have to. But this just shifts the dependency from individual platforms to the integration platform itself. True interoperability would mean standardized protocols. Imagine if every project management tool spoke the same language. You could switch from Asana to Linear to Monday without losing data or breaking workflows. This will never happen voluntarily. Platforms benefit from incompatibility. Switching costs are their competitive advantage. Open APIs give the appearance of openness while maintaining structural lock-in. The closest thing to real interoperability is export functionality. But exports are usually one-way, lossy, and poorly documented. Platforms comply with data portability regulations (like GDPR) while making actual migration impractical.

The Power Asymmetry

When you integrate deeply with a platform, you’re making a bet. You’re betting they won’t change the terms. You’re betting they won’t raise prices. You’re betting they won’t shut down. You’re betting they won’t pivot to a new strategy that excludes you. This bet is asymmetric. The platform can change the relationship at any time. You can’t. You’ve already built on their foundation. Twitter’s API history is instructive. They opened it in 2006 and encouraged third-party clients. Developers built businesses on Twitter’s platform. Then in 2012, Twitter tightened API restrictions to push users to their official clients. Many third-party apps died overnight. Twitter argued it was necessary for their business model. Developers argued it was breach of trust. Both were right. The platform had power; developers had investment. The platform won. This pattern repeats constantly. Platforms open APIs to build ecosystems, then restrict them to maximize revenue. The developers who built on the platform are collateral damage.

Generative Engine Optimization

The API economy is about to get stranger. Large language models can call APIs. This means AI agents will soon orchestrate integrations without human intervention. Imagine asking your AI assistant: “Schedule meetings with everyone who responded to my email campaign and add them to my CRM.” Behind the scenes, it would call APIs for your email tool, calendar, and CRM. It would handle authentication, data mapping, and error handling automatically. This sounds convenient. It’s also terrifying. You’re giving AI agents access to your entire tool stack. One prompt could trigger dozens of API calls across multiple platforms. Debugging will be nearly impossible. Platform vendors are already preparing for this. They’re building “AI-friendly” APIs with natural language interfaces. They’re creating agent-specific rate limits and pricing tiers. They’re thinking about how to capture value from autonomous integration. The lock-in dynamics get more intense. If your AI agent is trained on your specific integration setup, switching platforms means retraining your agent. The switching cost includes not just human learning but machine learning. Search engines are evolving too. Google and Perplexity don’t just index content anymore—they execute it. When you search for “book a flight,” the engine might call airline APIs directly. The website is optional. This creates new competition for platforms. Being findable in traditional search isn’t enough. You need to be discoverable by AI agents. This is generative engine optimization: structuring your APIs and data so machines can understand and use them automatically. Platforms that win this race will become infrastructure. Platforms that lose will become obsolete. There’s no middle ground.

graph LR
    A[User Prompt] --> B[AI Agent]
    B --> C[Email API]
    B --> D[Calendar API]
    B --> E[CRM API]
    B --> F[Payment API]
    C --> G[Unified Response]
    D --> G
    E --> G
    F --> G
    G --> H[User]

The scary part: most users won’t understand what’s happening. They’ll just know that their AI assistant “handles everything.” The integration complexity will be invisible. So will the dependencies.

What Actually Works

After spending months thinking about this, I’ve developed a mental model. Integrations are like debt. Some debt is productive. Most isn’t. Productive integration: Your accounting software talks to your bank. This eliminates manual reconciliation, reduces errors, and saves hours every week. The value is clear and sustained. Unproductive integration: Your project manager posts to Slack when tasks are updated, which triggers an email summary, which you ignore because you’re already in Slack. This creates noise without value. The difference is intentionality. Productive integrations solve specific problems. Unproductive integrations are enabled because they exist. I’ve started applying a three-question test before enabling any integration:

What manual process does this eliminate?
Would I notice if this stopped working?
Could I explain this integration to someone else in thirty seconds? If I can’t answer all three convincingly, I don’t enable it. This has cut my integration count by 60% without losing any meaningful functionality. The hardest part is resisting FOMO. When a platform announces a new integration, there’s social pressure to try it. Everyone’s tweeting about the Notion-Figma integration, so maybe you need it too. You probably don’t.

The Infrastructure Layer

There’s one category where deep integration makes sense: infrastructure. If you’re building on AWS, you should use their full stack. If you’re building on Vercel, use their edge functions and analytics. If you’re building on Supabase, use their auth and storage. Infrastructure platforms earn lock-in by being genuinely good. AWS isn’t irreplaceable because they make switching hard—though they do. They’re irreplaceable because they work reliably at scale. The switching cost reflects real value, not artificial barriers. The difference is technical depth. Migrating from Notion to Obsidian is annoying but achievable. Migrating from AWS to Google Cloud is a multi-year project requiring rearchitecture. The second scenario justifies the commitment. But even infrastructure platforms can overreach. AWS keeps launching services that compete with their ecosystem partners. They call it “customer obsession.” Partners call it predatory. The lesson: even in infrastructure, maintain optionality. Use abstractions that reduce platform-specific dependencies. Keep core logic portable. Design for eventual migration, even if you never execute it.

The Exit Strategy Nobody Implements

Every company says they avoid vendor lock-in. Almost none do. We tell ourselves we’re being pragmatic: “We’ll switch if we need to.” Then we never need to, because switching becomes impossible. The honest approach is acknowledging the tradeoff. Using a platform deeply means accepting dependency. That’s fine if the dependency is worth it. But it should be a conscious choice, not accidental accumulation. One practice that helps: annual integration audits. Once a year, review every enabled integration. Ask the same questions: What does this do? Is it still valuable? Could we live without it? Most integrations fail this audit. They were set up for a specific project that ended months ago. Or they duplicate functionality now built into one of your core tools. Or they seemed useful but never got used. Disabling unnecessary integrations reduces surface area. Fewer things can break. Fewer APIs to monitor. Fewer accounts to secure. Fewer secrets to rotate. The system becomes simpler and more robust. But this requires discipline. Integrations are easier to add than to remove. Removal requires coordination: “Who depends on this? What breaks if we turn it off?” Addition just requires clicking a button. The asymmetry favors accumulation. You have to fight it actively.

The Platform’s Perspective

I asked a VP of Platform at a major B2B SaaS company why they push integrations so hard. Her answer was surprisingly candid: “We know it creates dependency. That’s the point. Our job is to make our product indispensable. Integrations are how we do that. Every connection is a reason not to leave.” She continued: “But it’s not cynical. Integrations genuinely create value. Our users ask for them constantly. We’re responding to demand, not manufacturing it.” Both things are true. Users do want integrations. Platforms do benefit from lock-in. The incentives are aligned, until they’re not. The tension emerges when platforms change terms. They raise prices, knowing switching is expensive. They deprecate features, knowing users can’t leave easily. They add restrictions, knowing users have no alternative. This is rational business behavior. It’s also why users resent platforms even as they depend on them. The relationship is transactional, not collaborative. Both sides know it.

The Coming Backlash

We’re starting to see resistance. The “local-first” movement prioritizes tools that work offline and own their data. The “composable” movement advocates small, focused tools over all-in-one platforms. The “IndieWeb” movement rejects platforms entirely in favor of owned infrastructure. These movements are reactions to platform overreach. They represent real frustration with dependency, lock-in, and power asymmetry. But they’re still niche. Most users choose convenience over control. The backlash will likely follow the same pattern as privacy. Everyone says they care. Few change behavior. The platforms with the best UX win, regardless of their lock-in strategy. But regulation might change this. The EU’s Digital Markets Act forces large platforms to provide interoperability. This could standardize APIs and reduce switching costs. Or it could just add compliance overhead while changing nothing structural. The United States is considering similar legislation. So are other major markets. If interoperability becomes legally required, the API economy might shift from proprietary platforms to open protocols. But I’m skeptical. Regulations are slow. Platforms are fast. By the time rules are enforced, the platforms will have found new ways to create dependency.

What I’m Doing Differently

I’ve made specific changes based on this analysis: I’ve reduced my tool count from twenty-three to eleven. Each tool serves a specific purpose and doesn’t overlap with others. I’ve disabled integrations that don’t pass my three-question test. This cut enabled integrations from forty-two to sixteen. I’ve switched to tools with good export functionality. If I can’t export my data easily, I don’t commit deeply. I’ve started using API wrappers that abstract platform specifics. If the underlying platform changes, I can swap it out without rewriting everything. I’ve accepted that some lock-in is inevitable. I choose where to accept it deliberately rather than accumulating it accidentally. The result is a simpler stack that feels more manageable. When something breaks, I can usually fix it myself instead of waiting for platform support or checking status pages. This doesn’t mean I’ve abandoned integrations. I still use them where they provide clear value. But I’m more selective about what I enable and more aggressive about what I disable.

The Uncomfortable Truth

The API economy works because most of us want platforms to be our operating system. We say we value control, but we choose convenience. We say we want flexibility, but we pick tools with the most features. We say we hate lock-in, but we integrate everything anyway. Platforms are responding to revealed preferences, not manipulating us. They’re giving us what we ask for, even if it’s not what we need. The uncomfortable truth is that this is our fault as much as theirs. We enable the dependency by pursuing marginal convenience gains. We accept the integration tax because individually each integration seems reasonable. Only in aggregate does the problem become clear. By then, we’re too invested to change. This isn’t a problem with an easy solution. It’s a coordination failure built into the structure of modern software. Platforms benefit from lock-in. Users benefit from integrations. The two goals are fundamentally in tension. Maybe the answer isn’t to avoid platforms. Maybe it’s to engage with them more consciously. Choose dependencies deliberately. Maintain optionality where possible. Accept lock-in where it’s worth it. Or maybe the real answer is that the API economy is just how software works now. Fighting it is like fighting email or mobile apps. It’s infrastructure, not a choice. I haven’t fully decided which is true. But I’m watching my integration count more carefully. And when I see a new integration suggestion, my first thought is no longer “Ooh, useful.” It’s “What’s this going to cost me?” That shift in default mindset might be the only defense we have.