The Three-Legged Stool of API Companies
The Three-Legged Stool of API Companies
Perhaps another metaphor stretched too far...
People use the three-legged a metaphor in various spheres — retirement planning and value investing are two examples. The basic premise is that three dimensions prop up an overarching idea or broader category. Each leg is useless on its own, but together, they provide support and meaning to the concept in question. Recently, I’ve found the three-legged stool as a useful framework to evaluate API-driven business models.
Simplistically, infrastructure APIs enable developers to integrate products and services directly into an application, rather than having to build the micro-service themself or wrangle their finance + legal departments to work with a supply of fragmented vendors. These tend to make strong businesses because they have a recurring revenue stream (generally a take rate of transactions or subscription access), don’t require long sales cycles, and have high switching costs as middleware components. There are useful ways to think about other Internet-driven business models (marketplaces, SaaS), but fewer frameworks exist to help guide a discussion of API-centric companies. I’m by no means religious about but this heuristic, but would like to propose the three-legged stool of API companies.
1: Utility Source
I appreciate how Geoff Lewis and Bedrock Capital framed Clearbit (API for enrichment data) as an “Internet utility” in their blog post announcing an investment in the company. Internet utilities are widely available foundational services — protocols, datasets, functions. An API-driven business can do one of two things. It can act as an interface layer to make an underlying protocol more accessible. An example would be Dwolla and ACH.
The other way to draw on a utility source is for the API to orchestrate resources (human interaction, legal processes, fragmented vendor supply) and create a new Internet utility. The utility, whether built on or created, forms the basis for the success of the API business.
2: Apps
Second, developers and companies actually have to build services on top of the infrastructure layer one is putting in place. A utility can find pull from an ecology of applications, which leads to new configurations on that end. For example, Stripe’s thesis over time has not only been to serve businesses that accept payments on the Internet, but also to increase the throughput and velocity of that market itself. The market is fundamentally altered.
There are other ways founders building API-centric companies can learn about the inner workings of the application layer. Plaid built itself out of the strong needs of one customer — Venmo. The directional bet the founders took was that there would be a lot more Venmos down the road. All in all, no infrastructure API business is complete without its emergent or healthy universe of applications.
3: Integration Ecosystem
This leg is the most under-appreciated and perhaps the most non-obvious. While API companies are meant to be accessible and extremely developer-friendly, they need native distribution and integration mechanisms, and legacy companies that aren’t used to working with a micro-services architecture have to adapt. This explains the emergence of businesses like Rapid API, ReadMe, Kong, and Helm Services. In order to balance out the rest of the stool, an infrastructure API company has to be compatible with and acknowledge the integration ecosystem.
These three legs — as support structures that hold up API companies — may seem intuitive and obvious, but I’ve found the framing helpful to evaluate these businesses and see what the most important factors are in the long run.
If you have any thoughts, feel free to DM me on Twitter. All my writing can be found on my personal site.