Unlocking Value Creation Among API-first Companies

In the recent era of product-led growth, APIs and infrastructure plays have attracted less attention than we think they deserve. We love a seamless, intuitive product with a magical user interface as much as the next investor, but over the past six months, we have been shoring up our thesis on what’s driving the emergence of billion-dollar API-first companies and what creates a category leader in the space.

Six months ago, Smooch, an API-first company that Inovia invested in, was acquired by Zendesk. The lessons we learned during Smooch’s journey prompted a reflection on the nuances of building a category-leading, API-first business. Some of these lessons were learned firsthand, while others were learned at conferences and over YouTube by watching some of today’s tech titans talk about how they built those category-leading businesses. All of these lessons were pressure tested through conversations with the next generation of API-first challengers. We hope you find them as valuable as we did!

Lessons on building billion-dollar API-first companies

The notion of modularized access to critical infrastructure that enables key business operations is nothing new — AWS and the rise of cloud computing as a replacement for on-premise servers was the original wave of API-first companies. Modularized access to payment processing (Stripe, Ayden), telecommunications (Twilio, MessageBird), search (Algolia, Coveo), banking data (Yodlee, Plaid), and many other business operations soon followed.

We believe there is a circular effect between scalability and fragmentation that will result in a growing number of API-first companies. As APIs emerge and modularize access to critical functions of building businesses, economies of scale that benefit incumbents become far less important and the cost of building a software business falls. Challengers take advantage of this, some of whom go on to modularize access to additional areas of critical infrastructure and the cycle ensues. In practical terms, there’s been a step-function reduction in the cost of starting (and scaling) a company due to AWS and Google Cloud, and API-first titans like Twilio and Stripe deliver their services on top of AWS.

API-first companies fall within two buckets — direct and flowthrough businesses. A direct API provisions access to a hard asset that it holds internally — AWS, Stripe, and Scale AI are all examples of this. A flowthrough API pulls data from a multitude of other companies — Plaid and Mulesoft are examples. I tend to think of flowthrough APIs as barbells — the API itself sits in the middle and provisions access to data flowing from 2+ end points to recipients.

In evaluating what makes a category leader (and a worthy category at all), we look at value creation along four main buckets:

1) Is this a valuable problem?

This is one of the central questions we ask about every business — ultimately a company needs to be tackling a killer customer issue, not a minor pain point, to build enduring value. For API-first companies, we think there are three particular problems that are being generally being solved: dullness/democratization, complexity and fragmentation. Dullness/democratization has the smallest moat, but removing painful workflows from internal developers and/or enabling anyone in an organization to do what once required technical expertise can be valuable. Complexity typically occurs when it’s technically hard to time-consuming to build due to regulatory reasons, regulatory systems, or just true technical complexity beyond the norm. Fragmentation applies for flowthrough businesses, and the greater the abundance of supply on both sides, the more valuable the problem being solved.

2) Are there market tailwinds? What are the market timing dynamics?

A great signal of value is a gold rush that’s serving as a market tailwind. For Twilio, this was the hypergrowth of smartphones, while Mulesoft benefitted from the shift to cloud software and the ensuing explosion of SaaS businesses.

A secondary consideration here is the extent to which customers have invested in solving this problem themselves. Sunk costs aren’t unique to APIs, but particularly for a lower value problem you’re solving (ie. dullness), the build vs buy calculation might struggle to overcome the inertia of an internal solution.

3) Is this too valuable of a problem to customers for them to rely on an external party to solve it?

Providing net positive value (NPV) to customers is a foundational principle. NPV itself isn’t a unique concept — in all businesses, the ROI needs to outweigh the investment itself for customers to buy. The challenge for API-first companies is when NPV is so high, customers inevitably see value in building out this capability internally. We evaluate this dynamic by looking at how core to the customer ethos this problem is. Practically, we ask “is this required to deliver service and/or without it, would the buyer provide a markedly worse experience for their end customers?” This factor doesn’t live in isolation — an API-first business that’s solving a highly complex problem with significant technical moats is unlikely to see customers build a solution themselves, even if that problem is highly core to their business model. However, pricing power falls to the buyer rather than the service provider, and as competition builds, the provider is at risk of commoditization and a race to the bottom on price. Similarly, time to market can be more valuable for the API customer than cost in a fast-moving market, and thus we often see customers adopt solutions that are core to their ethos early on. However, as those customers achieve a market presence and enough scale to build themselves, the question of how core it is to their business model resurfaces.

On the other hand, companies like Twilio or MessageBird enable businesses like Uber to build more seamless pickup experiences for customers, but absent communication tools, the license plate and coloured windshield indicator are enough for the pickup to work.

4) How can this business create defensibility?

API-first businesses are always at risk of commoditizing into a pure utility; the challenge is to become a value-add utility that maintains a defensible moat. Even for a highly complex business with technical challenges (ie. Scale AI) or regulatory hurdles (ie. Plaid), commoditization is a question of if, not when. We look at two core building blocks within defensibility: tactical strategies of differentiation, and network effects.

Tactical strategies influence product design and the marketing playbook. Some businesses have focused on ease of use to encourage testing (ie. Aydin, Algolia, Smooch). Others are laser-focused on the developer experience, setting them up as a referral channel (ie. Twilio, Stripe (previously dev/payments), New Relic). Another strategy is focusing sales messaging on the value for end customers, making a bid for C-level purchasers who push adoption down within their organization (ie. MessageBird). Another tactic has been content marketing that highlights customers and their use cases — in the absence of a real product experience, it’s helpful to demonstrate customer experience (ie. Twilio, Zapier).

Network effects have historically been evaluated through the lens of the number and quality of integrations. This is a short-lived advantage as competitors will inevitably catch up. It’s also particularly vulnerable to sudden shifts in supply — leapfrog technologies that disrupt existing integrations in favour of a new pool of integration partners to be locked up. Given these challenges, we look for opportunities for API-first companies to leverage data and/or expand its reach into adjacent problems in order to become a value-add utility. The specific services that can be layered on top of the utility are informed by the data that flows through an APIs pipes.

We’re enthusiastic about the opportunities for many more API-first companies to emerge, as well as the generation of emerging businesses tackling discovery, collaboration, security, performance tracking, and other needs arising from the plethora of API-first businesses that have been created. If you’re working on something in this space, or have thoughts on the above framework, please reach out to sarah@inovia.vc to chat!