I’m fascinated by API-First companies and the way in which they take complex, messy problems and cleanly abstract them for their customers. This type of business has been popular in the tech industry for the past 15+ years. But to me, it still feels early and underutilized. Spero Ventures is excited about backing the next generation of founders that use an API-First distribution model to tackle worthy problems in our 3 core areas of focus: Wellbeing, Sustainability, and Learning/Work/Play

To ensure we’re speaking the same language: I think of a company as “API-First” if the service offered is comprehensively accessible via a read-and-write API. API-First does not mean “API Only”; instead it means that the API will always be a first-class citizen and is the primary means of interaction with the service offered.

What’s so exciting about API-First companies?

Companies that prioritize API as the primary means of interaction have exciting characteristics that companies in the same market with the same job-to-be-done lack. Here are some them:

Clean encapsulation

API-First companies offer a clean encapsulation of a problem. A well-written API exposes only the objects that an end consumer needs to worry about and abstracts away the middle layer of details—the ones  programmers would need to juggle if they built the service on their own. Encapsulation helps developers by removing them from the implementation details and nuances of a complex request. Companies that choose to offer a service without an API can often suffer from leaky abstractions in which the complexity of the service offered gets exposed as the UI becomes complicated or over-designed. Designers of successful APIs pride themselves on clean encapsulation.

Emergent use cases 

Another aspect of a well-written API is reusability in different contexts, which leads to highly emergent use cases. A poorly written API has methods that are very specific and prescriptive to a single use case. By contrast, a well-written API is often described as composable: it’s written flexibly such that it’s modular (can be used well in unknown contexts that are compatible with its documented inputs and outputs) and stateless (produces consistent behavior regardless of how the API was used previously).

For example, Twilio didn’t launch a highly specific SMS API with the sole intention that it be used only for multi-factor authentication (MFA) purposes. MFA was only one of many explosive use cases that drove a lot of growth. Instead, Twilio made a highly generic SMS API that enabled a wide variety of emergent uses, such as:

  • enable mobile users to send money (venmo)
  • group chat with friends (GroupMe)
  • ping their carshare driver (Uber)
  • …and, yes, of course, sign into services via MFA.

All of these examples are actual early Twilio SMS customers. A single API led to varied, emergent use cases that were not explicit design goals at the outset. Emergent use cases are surprising and exciting, particularly to a VC who’s seeking uncapped upside when making an investment. A known, definable, boxed-in market for a product doesn’t leave enough room to wonder “What If?…” But when an API is generic enough to be a building block, a developer LEGO, it can get incorporated into all kinds of masterworks of future architecture that the original creator couldn’t imagine a priori.

Permissionless innovation

A characteristic of the internet that made it so unique compared to all other media before it is permissionless innovation. You don’t need an FCC license for radio spectrum or land-use rights to lay telegraph wire to broadcast your message. You can self-host anything you want to make, point to it with an IP address, and be instantly accessible to half the globe. Being accessible doesn’t guarantee an audience will show up, but the network is open for your usage without a gatekeeper deeming your idea worthy before you build your thing. 

Well-constructed API-First companies rhyme with their internet origins in this way. Flickr is not an API-First company, but it’s an iconic example of the start of the API-fueled Web 2.0 mashup culture, and its API was an exciting part of that beginning. Caterina Fake (co-founder of Flickr) wrote in 2006 about Biz Dev 2.0. (The original post is lost to digital rot, but Archive.org to the rescue) From Caterina:

Fred [Wilson] contacted me about a small startup that wanted an introduction, but I said we (that is, Flickr) probably didn’t have the space on our schedules to engage with them in any meaningful way, but that they should feel free to apply for a Commercial API key and build something off the API. “BizDev 2.0” I call it. Nifty concept, sez Fred.

This is a key moment in internet history to me. It morphed the spirit of permissionless innovation that the web fostered into scalable business strategy. Don’t do a heavy-handed, top-down sale to a new customer for your service before you know if the customer is viable. Instead, offer an API-as-a-service with a simple enough sign-up flow that developers can help themselves, and then, once you see what gets built by potential customers bottoms-up, you can identify high-quality customers to target for deeper relationships.

Time-to-value & pace of innovation

Permissionless innovation often implies self-serve access to API keys, so developers tend to initially adopt API-first companies’ services without talking to anyone first, internally or externally. This leads to the next positive characteristic: API-First services often deliver faster time-to-value (TTV) for customers. There’s no need to deal with prolonged contract negotiations or a technical audit before experimenting with an API. Just grab the API and the docs, open a console, and build a proof of concept quickly to see if the API fits as a solution to the developer’s job-to-be-done. When Stripe launched, it was famous for having a dozen lines of code on its homepage that when copy/pasted into a console would trigger your first payment transaction. Compared to prior payment processor solutions developer experience (the best of this lowly lot was Authorize.net), this is an insanely fast time-to-value.

The speed benefit isn’t limited to just customers. Every enterprise software company has a layer of abstraction between its frontend and backend services. API-First companies benefit from faster pace of innovation because offering a developer an API saves time in frontend development and design. 

I don’t mean to be light about the difficulty of building a great API. New problems emerge instead, such as building in more robust error handling or rate-limiting, writing clear documentation with strong code examples, writing wrapper libraries for different languages and frameworks, cultivating a good community on github and stackoverflow (these are some of the niceties of a new, fast-growing discipline: Developer Experience (DX)). That said, API-First companies often have a culture of shipping often, and they prioritize engineering culture in a way that their more traditional enterprise non-API comparables lack, and this leads to a better pace of innovation. 

Grassroots adoption

Traditional enterprise software is often sold into companies top-down from the CIO/CTO/VP Eng for technical service offerings. Almost no one (except maybe Compliance/Legal) benefits from this top-down approach. Executives buying technical solutions aren’t close enough to the implementation details of the service needed to know if the product is a good enough fit to the job-to-be-done. Startups that are trying to convince enterprise executives to buy their software strictly top-down often struggle with credibility and need to partner with expensive valued-added-resellers or consultants. By contrast, the bottom-up adoption enabled by self-serve API-First companies makes everyone’s life easier. Developers can try solutions without waiting for a lengthy procurement. Enterprise executives can confidently expand the purchase of software they already know is providing value. API-First startups can focus their top-down sales efforts primarily on customers that are incredibly warm leads because they can see the organic usage of their sales prospects before the first call. This leads to the most common go-to-market strategy for API-First, a motion that starts on the ground where the development actually happens. That grassroots origin allows a thousand seedlings to sprout with a self-serve API key, and then a top-down sales approach can grow high-quality prospects into the next generation of oak trees.

Building around developers’ needs

API-First companies play into a ceaselessly growing macro-trend: the rise of developers. More people than ever hold the job title of “developer” of some sort today, and that number will continue to grow. We laugh at Steve Ballmer’s “Developers, Developers, Developers!” manic chant in hindsight, but Microsoft’s obsession with developers across 3 decades is why it’s one of the most valuable, enduring companies in the world. By building your software company in an API-First way, you hang a neon blinking sign on your homepage that announces you prioritize developers and their experience. More jobs than ever before are becoming some form of information work that can be automated by code, and building a company through this lens will help ensure that you’re on the right side of this trend.

While all of these characteristics above are great reasons why API-First companies are exciting, my favorite reason is all of the compounding growth loops that occur in well-built API-First companies. This next section will walk you through these compounding growth loops, loop by loop.

Compounding Growth Loops for API-First Companies

A common API-First company’s North Star metric is developer adoption, and the number of developers in an API-ecosystem tends to compound naturally in four growth loops that reinforce each other.


1. The Developer Experience (DX) Loop: Developers who explore (and eventually thrive) with the API will build compounding resources online that are key to great DX. Years of developers using the API leads to questions and answers on StackOverflow or pull requests and wrapper libraries contributed openly on GitHub. A groundswell of organic activity emerges around a successful API where developers help each other get through issues they encountered in the past together because developers are more altruistic than typical enterprise purchasers. This organic pool of resources and support gets indexed by Google’s crawler. The next generation of developers that are looking to solve a relevant problem will discover the API via Google. This brings us back to the start of the loop and increases developer adoption of the API.

2. The Consumption-to-Paid-Acquisition Growth Loop: The most direct business model to make money from an API is to charge for its usage. This consumption-based business model means that an API’s cash flow grows as: (A) more developers integrate the API into more apps, and (B) as the developers’ apps grow, their API consumption grows. 

First, developers integrate the API into more new apps. Each new app built will grow in usage over time, which leads to more API consumption. So, each individual app increases its spend with the API over time. As the API accumulates more cash flow, the business has more cash available for marketing to acquire the next cohort of developers. This leads to more developer adoption and the loop is complete. 

Related to this loop is the concept of net-negative churn: A given cohort of API customers will be larger one year later, as long as the usage of the customers who churn during the year does not exceed the natural expansion of the remaining customers’ usage. API-First companies with net-negative churn compound in growth even if they fail to add new cohorts of customers (a magical characteristic unique to subscription-based business models). Not all API-First companies will have net-negative churn, but the best ones all do.

3. The “Keeping Up with the Joneses” Growth Loop: As the API gets integrated by developers into new products, the API is being integrated for a reason that is likely aligned with the app’s end-customers’ goals. Stated more directly: the API makes apps better. A company might use an API to add a new feature (like SMS-based interaction (Twilio) or a better checkout payment flow (Stripe)) that makes its product more compelling and competitive. That company’s competitors will eventually notice the change and (probably) follow suit. So, for the best APIs, integration by one competitor will lead to a Red Queen Race. One product thriving thanks to an API causes competitors to adopt that same API, which closes the loop and adds more developers into the API’s compounding loops.

4. Data Exhaust Growth Loop: Last, many APIs get better as they get used more, thanks to a data feedback loop. As more developers integrate the API into their apps, the data and metadata that gets generated by usage of the API helps guide future improvements to the API. For example, when ecommerce merchants accept credit cards, they’re liable for chargebacks and susceptible to fraudulent chargeback claims. It’s very frustrating for merchants who have to provide evidence to contest chargeback fraud, and often it is easier to simply write off the fraud as a loss than to fight back. As Stripe’s API grew more popular, they saw more data and metadata about chargebacks. This is the data exhaust from the usage of the API. Stripe then developed machine learning algorithms to reduce chargeback fraud and improve the Stripe API for future users. (Not every API will have a compelling data exhaust growth loop. For example, if an API generates stock quotes, that usage isn’t adding data that will affect the stock quotes in the future. But this loop does exist for many APIs).

These four loops combine and reinforce each other. So, let’s look at the full picture as a whole now that we have decomposed it into its 4 component parts.

This compounding advantage becomes an enduring moat over time, which is why Stripe and Twilio are so highly successful despite pixel-for-pixel copycat clones of both services launching repeatedly over the past decade.

These characteristics are (mostly) universally true for API-First companies and are significant advantages over non-API competitors that don’t focus on API-First distribution and developer experience. That said, not all API-First companies are created equal. Some will have stronger growth loops than others based on execution choices and general quality. 

From here, I want to explore some side-avenue characteristics of API-First companies that are less universally true, but, to me, even more interesting.


Two archetypes of API-First services: Boxes and Platforms

API-First companies are exciting for the reasons I’ve discussed, but API-First companies can come in a variety of shapes, which can be exciting for their own reasons. Here I’ll explore two which differ materially: Boxes and Platforms

See this visualization first, and we’ll walk through a decomposition below.

Some API-First companies are Boxes (see left side of visualization above). They take messy, complex problems (like trying to get your application to communicate with the telephony and mobile SMS networks, in Twilio’s case) and then cleanly encapsulate it in a composable box (remember “composable” from our earlier vocab lesson?). Before Twilio existed, adding voice and SMS functionality to an app was a combination of agreements with various carriers, VoIP backhaul, Asterix servers, messy spaghetti code in multiple ‘70s era programming languages to communicate with carriers’ legacy systems, and network topography issues. After Twilio, it’s as simple as a couple API calls. Boxes are the truest representation of the titular LEGOs (or building blocks) of this post. Boxes tend to have obvious business models. They often sell a metered API, and developers pay in proportion to their usage. There are usually three parties in this equation: the vendors that the API encapsulates (for Twilio, the carrier networks), the first-party API (Twilio), and the developers that implement the API.

API-First companies can also be shaped like Platforms (see right side of visualization above). These differ from Boxes in that there is often a new party involved, a consumer of the Platform that isn’t the developer. Some obvious examples that fit this shape: Microsoft Windows, Salesforce/Force.com, and the iPhone. While these examples don’t look like API-First companies upon first blush, it would be an oversight to omit them from this framework because developer adoption is absolutely essential to their success, and without these developers they would quickly unravel (like RIM/Blackberry did). The Platform develops excellent, best-in-class APIs to allow developers access to the large audience the Platform has aggregated. Why is the audience there? Because they loved the experience that the prior cycle of developers built on top of the Platform, which made the Platform more attractive than alternatives. 

Platforms must overcome a cold start problem in order to grow. In the Platform genesis state, no apps exist yet, so the 1st party Platform owner will build the first couple apps, which are seen as inspirational reference designs for how great apps on the platform should work. The appeal of the 1st party reference apps helps recruit the first generation of users to the platform. (For example, Apple didn’t open up the iPhone to third-party developers until a year after the initial iPhone launch; in the beginning all apps were 1st party, and developer interest in building on the platform was at such a frenzy that they built jailbreak solutions and hacky, browser-based libraries to develop their own apps.) Once a platform has a healthy userbase, 3rd-party developers arrive and build 3rd-party apps using the Platform API in order to access the platform’s userbase. If these new apps are great, they’ll recruit even more new users that buy the platform and the userbase expands, which creates a reinforcing loop that recruits the next generation of developers to build more apps.

Platforms easily merit their own thesis document, and I don’t want to pull this article (deeper) into a digression. But it’s important to talk about Platforms in the context of API-First companies because (A) they recruit developers aggressively to develop for their Platform, (B) often Boxes aspire to become Platforms in the longer time horizon of their vision, and (C) Platforms’ developer recruitment efforts illuminate the reasons why a developer would choose to adopt a new API. I’ll explore developer motivations in the next section.

Developer Motivations to Adopt a New API

Regarding Developer motivations, why do developers choose a specific API? At the simplest level, it’s because it fulfills a developer’s job-to-be-done. While some of these jobs are niche or industry specific, many can be genericized into this framework. 

Developers want:

  • New functionality that’s hard to implement directly. This is the primary use case of an API like Nylas. Integrating customers’ calendars and emails is difficult to do directly if you want to cover all possible options like Microsoft O365, Exchange, Gmail, IMAP, etc… If you want to be able to access this type of data for your customer in both read and write functionality, it’s easier to just implement Nylas. APIs unlock new functionality that you can buy instead of building and maintaining it yourself.
  • Access to customers. Most relevant to Platforms, developers flock to APIs that will yield them new customers. Imagine a company that helps you with email deliverability. The functionality alone is good, but if it implements the Salesforce API and is discoverable in the Force.com ecosystem, then it’s suddenly instantly useful and discoverable to all the Salesforce users who care about communicating with their clients via email. If it’s a really great app, Salesforce might even actively promote it or co-sale your product because the developer implemented its API.
  • Access to a data asset. Data APIs are a straightforward use case. A developer wants to enable functionality in their app that requires data they don’t have. An API-First company can offer access to this data in a couple different business models: metered (pay-as-you-go) usage, freemium (pay once you hit a free usage cap), or premium access (pay a monthly fixed rate to access the data).
  • Money. Not all API-First companies are built on metered usage. Some APIs come with their business model baked-in, and therefore can pay developers to adopt it. Fred Wilson wrote a great example of this in regards to Indeed, a search engine for jobs, back in 2009:

In the case of Indeed, they initially offered online publishers the ability to pay for a real time search API of online jobs. Not many took them up on that offer. But when they injected their sponsored jobs into the API and offered to share the revenue with publishers, the demand was huge.

This clever move won’t apply to all APIs, but if advertising is a viable business model for an API-First company, then Indeed’s strategy may well work. Embedding the advertising into the API output gets additional impressions for the ads, and then you can give developers a share of the revenue they help generate. Getting paid to use an API you find useful for other reasons as well is a win-win. However, as a corollary to this Money example, I can recall a time when 2nd tier platforms (like Microsoft’s attempt to make a smartphone) would pay developers to use their API because the additional apps were strategic to the platform. When Apple was advertising “There an app for that” Microsoft needed an answer, and tried to buy their way to developer adoption. They failed because the Windows Phone platform wasn’t good enough, so despite paying developers to adopt their API, the platform floundered. Money will always motivate developers, but that can’t be the only form of value; the API or Platform still needs to be useful to the developer.

  • Access to a network. Arguably this is a subset of the “access to a data asset” case, as a network can be represented as data about relationships between nodes and edges, but it’s an important enough use case to call out on its own. Developers want their app to be maximally useful for their users. The more “networked” their app is, the better. For example, for every SaaS B2B board I have sat on, nearly always the first app that the company builds once their API is complete is a connection to the Zapier API network. By implementing with Zapier, developers’ apps will have basic interconnectivity with thousands of other applications immediately. Granted, their customers will have to pay for access to Zapier to enable these integrations, but some of their customers might already be Zapier customers, and some new customers might discover them via the Zapier ecosystem. So, accessing a network can motivate a developer to implement an API for varied reasons.
  • Better developer experience compared to competitors. All the above characteristics don’t suppose that two API offerings are in competition with each other. As the API-First ecosystem deepens, various categories have multiple competitors. For example, when considering how to integrate SMS functionality into an app, a developer might choose Plivo instead of Twilio. Price is rarely the most important factor in this decision, and competition creates cost parity anyway. A huge motivating factor is developer experience. Which API has the best documentation? More developer adoption? More StackOverflow and GitHub engagement? Developer experience is an essential motivating force, especially when an API implementation is often a choice that a developer will have to live with for a long time.

The best of API-First companies understand these developer motivations and use them to drive growth.

Spero Ventures and Why We Care about API-First Companies

At Spero Ventures we invest in founders building the things that make life worth living. We’ve decomposed this high-level mission thematically in 3 core areas of focus: Wellbeing, Sustainability, and Learning/Work/Play. API-First companies fit our investment thesis both horizontally and vertically. Horizontally, API-First is a distribution strategy that can apply in any of our 3 focus areas. For example, an API-First company in the sustainability area of focus that helps developers integrate carbon usage data into their apps to help make their customers more aware of their carbon footprint. Vertically, API-First falls under Learning/Work/Play as a category of technology enablement that’s changing how work is done. As more of today’s jobs become some flavor of information worker or developer, API-First companies are on the right side of history, aligned with how work will evolve. I’ve served on the boards of three API-First companies (Nylas, Particle, and Quantopian) and helped source other investments focused on developers, such as StackOverflow. If you’re building an API-First company and want to chat, email me: andrew at Spero dot vc