The Light and Dark Side of the API Economy
The “API Economy” is a popular term among VC’s and tech media, but I find it curiously unappreciated by developers. I think this is partly because developers know this revolution by other names (“SaaS” or “Devtools”) and partly because the term is more popular among nontechnical audiences. This causes developers to severely underestimate the importance of the API Economy to their own careers.
If you’re a developer, here’s my proposition to you: The API Economy is developers reshaping the world in their image. It is both a great opportunity for builders and a threat to people who cannot stay “Above the API”.
Let’s start by motivating the discussion with examples:
- AWS: the API for computer infrastructure
- Stripe/Shopify: the API for taking card payments
- Plaid: the API for connecting to bank accounts
- Twilio/Sendgrid: the API for sending text, email, etc
- Lob: the API for printing and sending physical mail
- Okta/Auth0: the API for authentication
- Checkr: the API for background checks
- Shippo: the API for shipping physical goods
- Flexport: the API for freight
- Stedi: the API for B2B EDI transactions
The most influential chart for me has been the Bessemer chart matching domains to logos in the API Economy:
There’s no definition of API Economy everyone agrees on. Even a16z, one of the biggest API Economy investors, don’t have a single blogpost on their site (beyond a podcast episode) dedicated to the idea. However you’ll find a lot more attempts at landscape charts by aspiring thoughtleaders, of varying quality with random crap thrown in depending on their point of view.
The API Economy describes how business functions are increasingly being offered as programmatic APIs for developers to use. It is the penultimate result of Software Eating the World. It overlaps strongly with the SaaS business model trend, but doesn’t fully circumscribe it, because customers typically pay by their usage of the API (instead of, say, per-seat).
If the only two ways to make money in business are bundling and unbundling, then the API Economy represents the developer-powered version of the Great Unbundling. In the old economy, we had to decide if an idea is a Product or a Feature. Even Steve Jobs thought this way. Today we know that we can offer features as products. As industries mature, they become more horizontal (I wrote about Horizontal vs Vertical businesses in my book). Tech is maturing, and every non-core feature is being extracted into its own horizontal platform.
APIs (Application Programming Interfaces) offer a clear contract of how a service can be programmatically operated by its users. It is often used in context of a programming language or framework, but equivalently an API Economy company offers APIs to its customers, who then pay per use.
By far the most important implication of the API Economy is how it empowers developers to build full fledged products faster.
Imagine the steps it used to take to set up an online-to-offline greeting card business like Postable:
- Rent a garage
- Buy server equipment
- Figure out how to take payments online
- Write greeting card generation software
- Hire humans to print and mail greeting cards
Notice that only one of those things had anything to do with your core differentiator. With the API Economy:
- Pick your server/serverless infrastructure from AWS
- Sign up for Stripe
- Write greeting card generation software
- Sign up for Lob
Your time to market goes from months to days.
In economics terms what we’re really talking about here is turning fixed costs to variable costs which makes sense for a startup getting off the ground. Rent, don’t buy.
However, it also makes sense for mature businesses, because centralizing infrastructure expenses creates incredible economies of scale. I like saying that I don’t need to spend any of my dev or founder time on building search capability, I can invoke the PhD-level expertise of Algolia or Elastic with a single API call.
That said, paid API pricing models can start to be extremely costly at scale. Most large customers don’t pay the listed API retail price for their scale, engaging in behind the scenes negotiations instead. Or you could decide that it would be cheaper to build the capability in-house. You have that power.
The good news is you didn’t need to build capability earlier when you didn’t have the information or the money, thanks to the API Economy. And because it is by definition programmatic, you are likely doing far more with fewer people on your payroll.
There’s also the more subtle point of incredible scalability, both in terms of spikes (scale up an order of magnitude in seconds, not months) and in sustained rates of growth (grow 300% a year with no change in code, no distracting purchasing process).
The clear contract of APIs is important. It’s kind of like the difference between having listed prices and “Call Us” for something you want to buy. Eliminating the extra friction reduces wasted time on both ends.
The contracts between companies tends to be much clearer than inside companies. Imagine having a “Search Department” with a whole team of devs there, compared to using a “Search API” from a dedicated company. It is likely that the API is going to be far better documented, with a clearer (and financially incentivized) SLA.
Of course, well run companies could theoretically have internal contracts as solid as external ones, but this is very rare.
A minor point, but an important one to make - Offering hosted open source as SaaS APIs is pretty much one of only two proven ways to fund development of open source (or at least open core) projects (e.g. MongoDB) at scale.
Having a daisy chain of dependencies for your business has two obvious downsides:
- your business goes down the moment any of your dependencies go down (aka your uptime is a
min()function of all their downtimes)
- your billing and account book-keeping is a mess
Matt Mullenweg has recently gone on record raising these criticisms of the Jamstack. There are, of course, counterarguments.
But by far I think the most underappreciated downside isn’t business, it’s societal.
The insight that APIs are easier and more straightforward to deal with than humans isn’t just a matter of office politics.
It’s also quite literally tearing our society apart.
Peter Reinhardt (CEO of Segment) once pointed out that the API Economy is bifurcating society into Above the API and Below the API jobs.
- Above the API: You tell machines what to do
- Below the API: Machines tell you what to do
The thesis being that those Above the API will amass economic power at a far greater rate than those Below the API.
The endgame implication is that we only use humans to do what machines can’t for now… and eventually replace them when machines can do it.
If you view Uber as an API (Press button, get on car, get off car), then the drivers driving Ubers are quite literally training their self driving robot replacements.
Look, obviously the analogy isn’t perfect and you can poke holes at it with counterexamples. But it is probably directionally correct.
Only 0.65% of the global population are developers (~50m of 7.5billion), people who can bend APIs to their will. We probably can’t realistically 100x the number of developers. What happens to those who fall behind the API?
First, the obvious. People who can stay Above the Kanban Board will fare better than those who are Below the Kanban Board. Being able to tell developers what to do has always been more effective than being a developer that gets told what to do. Figuring out how manage developers effectively to achieve business goals grants you unlimited power in the API economy.
For the rest, there is the GUI Economy.
Hundreds of millions of people use Excel. What if all the APIs we just talked about were accessible to regular folks, or “Citizen Developers”?
Welcome to the “No Code” movement. I wrote about this last year on the Webflow blog.
Just look at the Google search results for “API Economy”:
Entirely unappealing to developers. I know because I’ve spent hours trawling through these shitty results that have been SEO-ed to death by content marketers, trying to find a halfway decent definition to link to and failing. So this is my attempt at making one I’m happy pointing people to.