Disruption vs Enablement: API Startups

“AWS is a tax on the compute economy. So whether you care about mobile apps, consumer apps, IoT, SaaS etc etc, more companies than not will be using AWS versus building their own infrastructure. If you believe that over time the software industry is a multi, deca-trillion industry, then ask yourself how valuable a company would be who taxes the majority of that industry.”

- Chamath Palihapitiya, Founder and Managing Partner of Social Capital

This is part 6 of a 7 part series. If you haven’t done so already, you can read the first five posts here, here, here, here and here.

Within highly competitive industries where disruption is not an effective strategy, there can be opportunities to create value by impacting dynamics through the “enablement” of existing companies and/or people. When it comes to these models, we look to invest in companies that leverage technology to improve processes, provide tools that can’t be built in house (either due to an inability to hire and retain technical talent or because leveraging the data of all customers provides a better experience for everyone), or allow companies to access to new customers or serve them at a higher profit margin due to comparative advantage.

The first “enablement” strategy I want to focus on is the API (Application Program Interface), which abstracts away complexity to allow developers to easily integrate the underlying services into their applications. API’s work by allowing applications to talk to one another by calling a function that when executed provides access to a service and/or dataset. What I’m talking about in this post is commonly referred to as a “web API” which allows two web applications to talk to one another.

First, let’s start with a little history to see how we got to where we are today. If you look back at the history of computing, complexities are always modularized and later commoditized over time. In the early days, companies competed based on their hardware and unique software offered as part of that hardware. This lasted until the late 1980’s when Microsoft developed the PC platform which commoditized software, creating a ton of value as the mass majority of computer companies could focus on their core competency (hardware) while Microsoft handled all of the software.

While Microsoft had their own applications which captured the majority of the value due to them being the “Kingmaker”, developers also built new applications on-top of the Microsoft operating system sparking a vibrant industry of software products due to developer confidence in building software that would be compatible with the vast majority of the market.

In the 1990’s the Internet came along and commoditized operating systems with Linux as developers could then build applications (websites) that were compatible with all devices as long as they had access to the Internet via a graphical interface (the web browser). This sparked even more development as the Internet made it easy for developers to get distribution for their applications.

While there has been significant progress and many new developments since Netscape launched the first web browser, the crux of the ecosystem is still the same. Developers leverage the Internet for distribution with value coming in the form of network effects.

However, the other big development was in the form of what’s called “Infrastructure as a Service”. Amazon Web Services is the most well-known of many cloud-based services that commoditized compute power and data storage, massively reducing the upfront infrastructure costs of starting a technology company. In doing so, the idea of a data centre became extinct allowing developers to focus solely on the strength of their code and the usefulness of their application, nothing else.

The next logical progression is the API — developers shouldn’t need to build out a whole new payment system if their business is to sell sneakers, instead they should use Stripe, a company solely focused on building the best software for merchants to accept payments online.

Just as AWS allowed developers to focus on writing code and building software instead of provisioning servers, API’s modularize applications by allowing developers to focus on their core competency which is the usefulness of the application. This is how a 55-person company called WhatsApp was able to build a business acquired for $19B by Facebook.

Oftentimes API startups can build strong data network effects as the number of customers using the product increases. As more developers integrate a single API, more data is collected then in turn becomes more valuable for more customers, creating a virtuous cycle. Examples include API’s that collect location data and those that help to fight fraud. If the size of the network grows, API startups can collect data on more offline locations or learn the different types of fraud that occur on different applications.

The best API companies are those that take a problem that is core to their customers’ businesses yet isn’t their core competency and provides a simple and cheaper solution. These companies should focus on areas that are time-consuming and complex to manage, typically where either the supply is fragmented (most often in the form of data), frequently updated or difficult to manage technically. Thereby organizing it into one, easy to use function for developers to include in their applications adds tremendous value. This is also quite sticky (which VC’s like because it offers long “lifetime value”) due to the fact that the developer of the API is responsible for keeping the service and/or data up and running which includes updating the dataset, keeping it stable, and increasing its features and functionality.

Now, starting a company built around an API isn’t easy. API businesses need to be built for highly fragmented industries to ensure there’s a large customer base to make the business feasible.* APIs can potentially be effective or valuable across a number of industries including horizontal and vertical SaaS, social, e-commerce, etc. If the core value proposition of your API business is to save people time and reduce complexity, the offering must be cheap (usually under $1 per API call), otherwise your customers will build it by themselves or competitors will compete on price.

While this is an important box to check when aiming to build a venture-backed company with an API, maybe even more importantly is that the API is created during some sort of “gold rush”. For example, Twilio (API for voice, SMS and messaging capabilities) scaled quickly at least in part due to the hyper-growth of smartphones (as mentioned previously in regards to WhatsApp which is a Twilio customer). As more people carried supercomputers in their pocket, apps were developed allowing users to do certain things that weren’t previously possible such as hailing a ride from their phone or communicating in an “always-on” fashion without being tethered to a desktop or laptop computer. As more of these applications continued to be imagined, it became apparent that communication between people through these devices would be core to their usefulness. Rather than the developer(s) of each app having to spend time and money on building a global communication network, Twilio handles all of this complexity for them which they can integrate directly into their apps.

Additionally, it is best for an API to be called frequently on your customer’s application by their users. For example, Twilio’s customers are companies like WhatsApp and Uber where text messaging isn’t core to their value proposition but it is core to their service. The same goes for Plaid which provides convenient access to normalized banking and financial data opening up the opportunity for a flood of new fintech applications that improve consumers’ lives. This is important to note as sometimes decreasing complexity and reducing the barriers to entry can also aid in opening up a large market as developers discover many different use cases once the bar to access to a certain service is lowered.

Just as AWS is a tax on the Internet, API’s need to be a tax on large and fast-growing industries and services that are able to support millions or even billions of calls in order to build a successful business.

While not compulsory, API startups should bring real and very clear ROI in terms of time and money saved to developers by abstracting away a function that causes a great headache and materially impacts their bottom line. For example, in theory, companies using Shippo (an API that connects to a global network of shipping carriers) today could use a single carrier for shipping and not pay for the third-party API, however the $.05 cost per shipment the company charges seems trivial when you consider shipping carriers’ opaque pricing and legacy technology. This is akin to the idea of “comparative advantage” in economics defined by when an individual or group can produce a good or service at a lower opportunity cost than others. Since the company building the API focuses solely on the API’s functionality and the value it provides is typically a headache for its customers, both customers and the API startup gain from working with one another.

Once again using the tax analogy, this tax needs to be one that is a small price to pay relative to the value it brings either in time/cost savings or an increase in revenue through features, transactions or users. Having this functionality allows app developers to increase the functionality of their service, thereby increasing its value. You wouldn’t open up a restaurant that charges a significant premium for the same or worse quality food that people could cook at home unless the experience was significantly better and therefore the premium is justified by your customers (or in the case of fast food, the lower cost and time saved justifies the difference in quality versus cooking your meal at home).

There aren’t a lot of areas where these dynamics exist and therefore there hasn’t been a plethora of successful startups building individual API’s. With that being said, in order to build a massive business where the core product is an API, there are several different dynamics at play which can either increase or decrease that likelihood of success. When thinking about where this type of startups works best, the factors to consider are:

• If the industries that make up your potential end users are in aggregate large enough to support a very large number of API calls per year,
• If something has changed that is exponentially increasing the need for the data and/or functionality your API provides,
• How core it is to this “new economy” and therefore if the use case is frequent enough to support your costs of development; upkeep; and sales,
• Whether or not there are a plethora of use cases previously unimaginable before you launched your API,
• If the “supply” that makes up the value you’re providing is difficult to manage whether that’s measured in time consumption, cost or complexity,
• If your tax is valuable enough to provide net positive value to your customers whether it’s decreasing complexity through time, cost or increasing the number of users or transactions,
• Where the defensibility or moat for your business created for example by data network effects or the virtuous cycle of product improvement.

Case Study:

Funding: $440M

Outcome: While the company hasn’t been gone public or been acquired yet, Stripe was valued at $9B in their last round of funding raised in November 2016. By all accounts, from the outside, Stripe has become a very valuable and successful company. Customers using Stripe include Macy’s, GE, Adidas, Slack, Yelp, Nasdaq amongst many others.

Worked: Stripe

• Is the industry large enough to support a large number of API calls? Yes, payments is something that is at the heart of every business that offers the ability to transact on the Internet. Even just a small slice of this market and a small cut of each transaction can be enough to build a billion dollar business off of.
• Has anything changed that is exponentially increasing the need for the data and/or functionality provided? Yes, the Internet and new distribution channels (Facebook, Twitter, Instagram, etc.) have chiseled away at the economics of scale that big retailers and media companies were built upon. As a result, anyone can open up an e-commerce store, subscription service, etc. as long as the quality of their product warrants sharing and viral growth.
• Is it core to a “new economy” and therefore is the use case frequent?Yes. As mentioned above, this new breed of micro-entrepreneurs continues to grow exponentially and unlike the large corporations they would’ve had to have been a part of previously, they don’t have the capital or infrastructure to support services such as payments that are core to the success of their business but not their core skill set so they’re better served by using a product like Stripe while focusing on what they do best.
• Are there new use cases previously unimaginable that have been created? This isn’t necessary here given the initial addressable market and the growth in need for Stripe’s product although Stripe has gone above and beyond to create more services core to starting a new business from scratch which in the future could enable more people to leave their jobs and start businesses by using these tools and services.
• Is the “supply” that makes up its functionality difficult to manage? Yes. Payments is a notoriously difficult product to build. It’s not only time-consuming and complex but the upfront costs are high to developing your own payments gateway and you have to integrate multiple payment processors who have a time-consuming certification process, not to mention adding new features as customers come to expect new options and payment types. You’d also have to create your own settlement reports (account activity) because the payment processors provide them in raw format.
• Is it valuable enough to provide net positive value for customers? Because payments are at the heart of every transaction and therefore business, allowing content creators to focus on content or merchants to focus on acquiring customers and the quality of their product, helps to increase profitability for Stripe users. At the same time, just by abstracting away the complexity mentioned in the last bullet, in addition to time-saved, it’s likely that Stripe is also a cheaper option for its customers than building their own payment gateway.

Takeaway: Stripe is one of a few companies that really does pass the “API startup” criteria with flying colors. It adds a significant amount of value, is difficult to manage otherwise for all potential customers, and it’s a repetitive use case and at the core of their customers’ products yet isn’t their core competency. Stripe is a good bet to become a public company in the not-to-distant future and is likely to continue to be a mainstay in businesses’ toolkit.

Didn’t Work: Standard Treasury

Funding: $2.7M

Outcome: Standard Treasury was acquired by Silicon Valley Bank in August 2015. While the acquisition amount wasn’t made public, Standard Treasury was by no means a failure or unsuccessful outcome but rather it can be concluded that their vision of building standard API’s to facilitate transfers and other transactions with banks was not fully realized prior to the acquisition. Before the acquisition, Standard Treasury had pivoted their direction to build their own bank with a standard set of API’s for other companies to use in order to offer banking services to their customers.

• Is the industry large enough to support a large number of API calls?The banking industry is massive. There’s no need to bore readers with statistics to back that up. The issue though is that it’s fairly concentrated which makes it difficult for startups to penetrate given the lack of a “halo effect” that exists. Another problem for Standard Treasury and other companies in this market is that they’re faced with an endless number of risks related to regulation when it comes to working with banks. Once the company pivoted, the new direction was limited by the number of fintech startups with a need to offer banking products within their applications which is a much smaller addressable market.
• Has anything changed that is exponentially increasing the need for the data and/or functionality provided? The premise was predicated on the push towards more consumer-friendly banking. This would allow a bank’s customers to use digital services.
• Is it core to a “new economy” and therefore is the use case frequent?While there are many companies that would benefit from using banks’ API’s in order to serve their customers using a banks products and services, banks are already very large and profitable. Therefore, while it’s more to a “new economy” on one side of the coin, on the other side it’s not and therefore the attention and work necessary to push banks to adopt these new technologies was likely a very slow and difficult process.
• Are there new use cases previously unimaginable that have been created? Given that the company wasn’t around long enough to fully realize their vision, it’s hard to say whether or not there would’ve been previously unimaginable use cases resulting from developers having access to bank API’s although it’s certainly possible.
• Is the “supply” that makes up its functionality difficult to manage? Yes, it’s very difficult for companies and developers to interface with and integrate a bank’s products into their applications today due to the lack of API’s and standard infrastructure needed to do so. In this regard, Standard Treasury’s vision was the right one in working with banks to secure and open up their products in API format for others to use.
• Is it valuable enough to provide net positive value for customers?Piggybacking on the question of whether or not there are previously unimaginable use cases, it’s difficult to tell whether or not this provides net value for customers. However, it’s not too bold to state that giving developers access to banks’ APIs would make their applications for valuable given the different features they’d be able to give their users access to using their own bank accounts. With that being said, the issue is less about the net positive value to customers on the developer and application side of things and more about the net value to the banks themselves, a necessary domino that would need to fall in order for this vision to come to fruition.

Takeaway: Standard Treasury checked a lot of the boxes and all early stage companies will be taking at least one leap or faith or two when it comes to the market. In this case, banks unwillingness to move and difficult regulatory environment was a risk worth taking even if it didn’t pan out due to the fact that their “supply” is very complex and difficult to access and it’s likely that in doing so they’d be adding a significant amount of value as well as create new opportunities for future fintech startups. Because the banks wouldn’t budge fast enough and the regulatory environment prevented Standard Treasury from being able to become their own bank, the company wasn’t able to grant access to the supply side of the API in a way that would allow them to build a big, successful standalone business.

— —

*I’d be remiss if I didn’t mention the fact that the rise of serverless applications, specifically Amazon Lambda, which has begun to lay the groundwork for developers to monetize and build standalone “small businesses” by getting paid only when a function is called. Similar to the way that the App Store allows mobile app developers to make money by selling their app on a per-install basis, there is now an incentive for developers to build API’s that don’t necessarily need to have addressable markets the size of VC-backed startups.