I’ve been studying API companies Stripe and Twilio since they hit the scene, first as an early user and customer of each. For the past 5 years, I’ve been running Keen IO, an API business which is modeled after both of them. These two companies, as well as SendGrid, are the elite examples of turning an API product into a business.
Here are the steps as we saw them and tried to reproduce them at our company, to some degree of effect, in our own market, broken down into 5 steps.
In a self-service business with bottom-up adoption patterns, product is the most important ingredient in growth. In the API business specifically, this means first and foremost clean documentation around an elegant, painless, and rationally-designed API, plus a suite of SDKs that speak the local language without an accent. This sort of design is an exercise in threading the needle: if the API is too high-level, it won’t be customizable enough for broad developer adoption across use cases — and if it’s too low-level, it won’t be learnable enough to minimize time to eureka moment, nor expressive enough to minimize time to value. The true north in API design is to abstract away the messy, the repetitive, and the complicated — but to do so while still exposing enough flexibility/configurability to be useful in a variety of use cases, capturing nascent sub-markets quickly (and even without investment), before any non-API companies can form to address them. This is a critical advantage to future monetization, because the product’s Total Addressable Market (the sum of these sub-markets) grows on its own, in a more-or-less unbounded fashion.
Telegraph that you’re a member of the developer tribe. The marketing sites, branding, documentation, and even HTML source code of Stripe and Twilio scream “there are legit software developers in charge of these companies.” While developers are growing in power and influence in the corporate world, that progress is uneven: only a small minority of companies have developers at the helm / on the board / in the C-suite, which means it’s still novel to see such tribal signal from a potential vendor. Since people like to buy from people like themselves, this gives these companies a huge advantage when it comes to selling to — and therefore selling through — developers.
Create a global path to viral growth with a high K-factor. As I heard James Lindenbaum (founder of Heroku and Heavybit Industries) say a number of times: developer marketing has many elements of consumer marketing. Like all humans, developers like to find new products through word-of-mouth and their social graph. Unlike most humans, developers are not very susceptible to more in-your-face forms of persuasion, which makes word-of-mouth particularly important in this market. More than maybe any other profession, the viral distribution graph of developers ignores vertical (industry) and geographic lines, in favor of tech stack, community support, use case, and the social signals of who is using it (as Tim O’Reilly said, Follow the Alpha Geeks). How tactically you encourage this viral growth, once it exists, can vary: Twilio and SendGrid deployed dozens of magnetic, authentic developer evangelists on airplanes to visit local dev communities year-round; Stripe took another angle, focusing on online community & developer content channels. In the end, this leads to low (often zero) cost of sale, plus any paid customer acquisition costs are subsidized by the free acquisitions they bring downstream.
Utility pricing: metered, transparent, pay-as-you-go
As Jeff Lawson said at a recent conference, a revenue-generating customer starts at 1 cent. Sure, an account can grow to millions of dollars, but they don’t have to start that way, and pricing in this manner allows your customer’s monetary commitment to escalate gradually instead of in a step function. And yes, all things being equal, the finance people at the buyer would prefer monthly or annual consistency for all of their bills: but the engineering staff (closer to the utility and to the math driving their bill) sees things differently. Bundled, reserved, and flat-rate pricing can always be negotiated for enterprise and mid-market customers, but you won’t even get a chance to talk to a lot of mid-market customers unless their developers like your pricing model on the website.
There’s also a cultural advantage for the API company itself: usage-based pricing makes it possible to align the entire company around driving platform usage. Don’t underestimate the power of that alignment when compared to companies whose factions have warring incentives (for instance, at an open-source company who sells premium support packages, sales often develops a distaste for the free offering or the online community when it gives an alternative to buying anything). Hosted offerings can avoid this sort of problem altogether.
Customer support is sales — especially at first
Selling in this very different world requires a very different kind of sales motion. The inbound engine, viral growth, micro-transactions, and Power Law Distribution of account size mean that the very commercial nature of this business is more FarmVille than Workday. As such, digital onboarding, tutorial content, and especially customer support, are more important to get right first than sales and account management. Remember: driving usage is how you drive revenue. Later, once you add sales to the mix, this doesn’t really change because accelerating usage is the best way to start sales conversations. Each of these companies have really excelled at putting this new mode of thinking into practice.
This piece was adapted from a Quora post you can find here.