The API Economy and Why Your Software Is Now a Platform

In 2009, if a startup wanted to accept credit card payments, they needed a merchant account, a payment processor relationship, and usually a lawyer to review the contracts. It took months and cost real money before a single transaction could occur. Then Stripe launched, and the same startup could accept payments in 40 countries with a few dozen lines of code and a weekend's work. The entire payment infrastructure stack, the banking relationships, the fraud detection, the currency conversion, became a function call.

That shift is what people mean by the API economy, though the phrase has gotten vague from overuse. An API (Application Programming Interface) is how software systems talk to each other in standardized ways. The API economy is the pattern where companies expose their core capabilities through APIs and make money by letting other businesses build on top of them. Twilio did this with phone calls and text messages. Stripe did it with payments. Sendgrid did it with email delivery. In each case, the entire product is the API, and the revenue model depends on other businesses integrating it into their own products.

The strategic logic underneath this is platform theory. Parker, Van Alstyne, and Jiang (2017) drew the distinction between pipeline businesses and platform businesses, and it applies cleanly here. A pipeline business creates value in a linear sequence: raw materials come in, processing happens, a product goes out. A platform facilitates interactions between parties who would not have found or transacted with each other otherwise, and the platform owner takes a share of that value. An API-first company is a platform business in a particular configuration: developers are one side of the market, end users are the other, and the API is the interface through which both sides create value the platform then monetizes.

What makes this sticky is the dependency chain it creates. Every developer who builds a product on Stripe's API is a developer whose product now depends on Stripe continuing to exist and behave consistently. Switching costs are not primarily monetary. They are architectural. If you built your payment flow around Stripe's webhooks, their idempotency model, their dispute resolution API, your product is Stripe-shaped. Migrating to a competitor means rebuilding that shape. This is not an accident. The switching cost is part of why API-first companies invest so much in developer experience: the more integrated the API becomes into a developer's thinking and codebase, the higher the cost of leaving.

AWS is the clearest example of this at scale. Amazon Web Services offers hundreds of services, and most sophisticated cloud architectures use dozens of them. By the time an organization has built around DynamoDB, SQS, Lambda, API Gateway, Cognito, and CloudWatch, the architecture is not just "on AWS," it is AWS-shaped. Each additional service deepens the integration and raises the switching cost. That dependency is the moat. Not any single service's feature set, but the accumulated architectural entanglement.

Salesforce's AppExchange, launched in 2006, is an earlier version of the same logic. Salesforce exposed its CRM data and workflow through APIs, invited third-party developers to build applications on top of it, and built an ecosystem of thousands of products that all depend on Salesforce as the platform of record. Those third-party applications make Salesforce more valuable, which attracts more customers, which attracts more AppExchange developers. The ecosystem is self-reinforcing, and each extension of it raises the cost of switching away from Salesforce for any individual customer.

The organizational consequence for non-tech companies is significant and often underestimated. The barrier to building digitally capable businesses has dropped considerably because so much capability is now API-accessible. A retailer who wants to offer same-day delivery does not build routing optimization algorithms from scratch. They call an API. A healthcare startup that needs patient identity verification does not build a verification system. They call an API. This is good: it lets small teams build things that would have required large engineering organizations a decade ago. But it also creates dependency chains where a single API provider's outage or pricing change can break many downstream businesses simultaneously.

AWS service outages are well-documented events, and when they occur they tend to take down large portions of the internet at once, because so many services depend on the same infrastructure. This is the structural risk that the API economy creates: concentration. The more efficient the market becomes at reusing commodity capabilities through APIs, the more those commodity capabilities concentrate at a small number of providers. The efficiency and the fragility come from the same source.

I think about this alongside what I wrote on platform governance and multi-sided markets. The API-first platform and the traditional platform have the same governance structure: the platform owner sets the rules, controls the interfaces, and decides which complementors get access and on what terms. When Stripe changes its fee structure, you can disagree, but you probably cannot leave easily. When AWS deprecates a service, you adapt. The dependency that makes these platforms valuable to developers is the same dependency that gives the platform owner structural power over everyone building on it.

There is also a useful IS frame here from resource-based view and IT competitive advantage. The capability exposed through an API is, from the provider's perspective, a resource that is rare (they built the banking relationships, the infrastructure), valuable (other businesses will pay for it), and at least partially inimitable (the network effects and regulatory relationships are hard to replicate). From the consumer's perspective, the API is a commodity they can access without building the underlying resource themselves. The API economy is, in some ways, a market for bounded access to resources that are inimitable only at the level of the provider.

The thing that gets obscured in the enthusiasm around composable architecture is that "composable" and "dependent" are the same thing, viewed differently. You compose your product from Stripe, Twilio, Auth0, and Sendgrid. You also depend on all four of them simultaneously. When any one of them has a problem, your product has a problem. The more sophisticated your composition, the more potential failure points you have accumulated in services you do not control.