On APIs and SaaS Unit Economics

In the first article in our seven-part series (APIs are Everywhere An Intentional Choice: Being API First), we detailed that while APIs are everywhere, the implications are underappreciated. In discussing the strategic considerations of being API first, we answered key questions including, "What makes a good API?" and, "What does it mean to be an API-first company?"

This article will comment on the role APIs play in SaaS unit economics and how these power dynamics have fundamentally altered the long-run view of customer experiences and buying expectations in financial services.

Read all seven parts here:

Part 1: APIs are Everywhere — An Intentional Choice: Being API First

Part 2: On APIs and SaaS Unit Economics

Part 3: On Market Power — Who Reads, Who Writes, Who’s SOL

Part 4: A Fork in the Road for Traditional Banks

Part 5: Impacts of BaaS Intermediation on Embedded Finance

Part 6: API-first development: fuel for regulations, Open Banking and Standardization

Part 7: The No-Code/Low-Code Accelerant

RIP ASPs.

Let’s start by pouring one out for the legacy application service providers of yore.

Gartner defines them as:

An application service provider (ASP) is defined as an enterprise that delivers application functionality and associated services across a network to multiple customers using a rental or usage-based transaction-pricing model. Gartner defines the ASP market as the delivery of standardized application software via a network, though not particularly or exclusively the Internet, through an outsourcing contract predicated on usage-based transaction pricing. The ASP market is composed of a mix of service providers (Web hosting and IT outsourcing), independent software vendors and network/ telecommunications providers.

These are your SAPs, NICEs etc. of the world—they're still globally vital and play a role in many enterprise software deployments. But consider for a moment all the legacy tech deployment in banks that effectively create huge deadweight losses because they are too cumbersome to fill new whitespace as the world changes around them[1]. Despite still having incumbent status all over the globe, these software products emerged in an era when the market sought 1:1 replacements for different parts of the customer value chain.

These 'OG' B2B vendors were synonymous with long, onerous implementations. They forced their customers to adapt to the vendor’s way of doing things and charged extra for services that were needed to ensure their software worked in the customer’s system.

The consumer suffers and the vendor lacks uniform repeatability at scale.

One of Amias’ friends was a salesperson at a SaaS company that was acquired by one of the giants. On his first day in the new company, his new boss sat down with him and asked, “OK, so how do we use your software to sell consulting and implementation services?” Shocked—“the whole point of software as a service is that the product keeps improving and you don’t need to sell...services,”—he thought as he politely nodded. Needless to say that he and the rest of the team left the giant to start a new company as soon as their earnouts were complete.

Meanwhile, the vast majority of fintech startups (both B2B and B2C) are gravitating toward ‘usage based/recurring revenue’ or subscription-based models—definitionally software-as-a-service (SaaS).

SaaS Unit Economics, A Recap

Banks need to remember this: the number one strategic imperative of every software company is to become a SaaS company. This sounds simple...every tech company is claiming to be a SaaS company anyway. But being a SaaS company is not just a fashionable label. It is an identifiable economic business model whose soaring valuation multiples appear to be sustainable judgments of their long-term economics, not just a faddish mania among investors.

One simple way to think about SaaS economics is a relationship between an hour of developer time and enterprise value. SaaS economics are characterized by gross margins of 60 percent to 80 percent, often higher, and the cost of revenue decreases since every line of code can be copied into the software of all customers. With lower R&D costs coupled with greater deployment efficiency, SaaS companies ship greater marginal utility more quickly and can steadily increase fees without losing customers—a dollar of revenue today is worth more than a dollar a year from now. The impact? SaaS companies have the two properties that investors crave the most—diminishing marginal cost and extreme scalability. These two operational features drive SaaS valuations and are the holy grail for tech CEOs and the investors who back them.

The other wonderful thing about SaaS unit economics is revenue protection. Great SaaS companies force their customers to answer the following question: why incur switching costs if the current product works and gets better month-over-month, year-over-year? The deeper in the customer’s tech stack that a SaaS company can provide value, the higher the other downside risks become—training, hiring, security, switching etc. Stickiness plus lock-in equals negative churn.

API-first unit economics—same but different

To go back to an earlier metaphor, the broader fintech landscape is quickly morphing into an ecosystem of legos, where the market is continually calibrating between internally built or externally licensed products and services. But whether home-built or purchased, these services must be pluggable and interoperable to be worthwhile.

The customers’ desire for lego bricks and the SaaS companies’ desire to be embedded in infrastructure, combined, will continue to drive software providers to become API-first companies. But the APIs have to be monetized in a distinctly different way from most SaaS today.

First, APIs should have lower switching cost than traditional SaaS. An API-first approach demands stronger standardization (see: Swagger, OAS etc.). In an era punctuated by support for new standard models like Open Banking and Open Healthcare and recent regulations like PSD2 (more on that later), the market itself has continued to apply pressure to software providers to adopt common standards that participating vendors and institutions can rely on to work with mutually intelligible input and output (more on that in Article 6 in our seven-part series). And historically, the highest switching cost in technology is training employees and developers—but APIs allow for a higher degree of decoupling across tools and business units, so “learning” new APIs is not strictly that difficult.

Second, because APIs are inherently self-contained, the natural upsell/cross-sell opportunities are more at the will of the customer than at the will of the vendor. Choosing to use any given API from a company does not strictly lock you into their entire ecosystem. Using legos grants architectural liberties, though that also includes ease of replacement, risk of churn, and overall revenue volatility. On balance, the strongest API-first companies are adept at creating complementary products (each with their own API endpoints) that make incremental adoption easy and painless. Nevertheless, these companies drive customer lock-in by choice, not by force, and therein lies another key distinction.

Building and maintaining great APIs is a cost-effective strategy. But it’s cost-effective for all API-first players, so as API providers’ COGS gets cheaper, sellers lose pricing leverage and revenue protection as switching costs become lower. APIs have great COGS and the market knows it, so expectations around willingness to pay pressure API providers to price their baseline licenses lower than SaaS. Consequently, API-first approaches converge on competition at the product/utility and value level, not at the price level, giving API consumers a much larger degree of purchasing freedom than their SaaS-purchasing counterparts.

Traditional SaaS is priced on a per-user basis, so unless your customers grow or shrink significantly, SaaS deployments tend to have very predictable revenue. No seasonality, no surges and stops, just clean, predictable growth based on churn and upsells.

In contrast, APIs tend to be priced based on how much they’re actually used. Each time a user submits a request or extracts a unit of data, they pay a small toll. Like we said, this means that revenue can be much more volatile than classic SaaS.

But, there is broad recognition that these usage-based models can be just as powerful as traditional SaaS, though they must be managed and valued differently. Our friends at OpenView partners have an excellent overview of this trend in general tech here.

So the greater degree of difficulty for cross-sell, the higher risk of churn and greater revenue volatility means it's looking likely that API-first companies will not fit the same economic model as a pure SaaS offering. Should those companies or their investors worry?

API-first growth strategies—benevolent complementarity

Because API-first offerings must be self-contained, API-first companies cannot ‘gotcha’ their customers into upsells and cross-sells. Instead, account growth is organic based on smart productization of complementary offerings. Here’s how it plays out.

First, deployment repeatability gives API-first companies a unique economy of scale. Remember that SaaS economics are defined by constantly improving software; API-first economics also need to be defined by this constant improvement, but the improvement tends to be measured in more nuanced ways. Such companies shouldn’t change the fundamental inputs or outputs (you can’t change the shape of a lego block that’s in your Harry Potter castle!). This constraint forces hyper focus on the scalability of the product: the latency, reliability, resilience and scope of methods. Every business process will have bugs and exceptions; API-first companies compete by limiting the extent to which their deployed services ever appear as a root cause in those exception processes.

Second, repeatability gives API-first companies the right to deploy new, closely related and complementary functions for their customers. “Hey, we know that you’re using our API to get location data on your customer’s transaction, we now have the ability to give you device fingerprint data as well. Would you like that?” This is the second key advantage that API-first companies should be able to build: speed to deploy and speed to link complementary services over time. Being API-first is hard work, but once some of the groundwork is down, the discipline of atomic thinking and the modularity inherent in the product tends to make launching new features and functions faster than others. Moreover, increasing the number of systems and number of functions that include your API creates a defensible feedback loop, so the long-term value of achieving a first-mover advantage is high.

Third, API-first companies are ecosystem accelerants and increase the value of players both above them and below them in the tech stack. API-first companies are naturally symbiotic—they succeed when the companies around them in the ecosystem succeed. Whereas you can have a somewhat successful standalone SaaS solution, you cannot have a successful standalone API implementation; it defeats the point. So the greater the interoperability—a proxy for stickiness—the easier it will be for customers to invest and deploy new use cases building on top of API functionality with which they're already familiar. The result? Great API-first companies will demonstrate both strong organic in-account adoption and gross retention.

Fourth, as an API's set of available functionality grows, the amount of value per unit added to the code increases as long as the API supplier has a sufficiently diversified customer base (horizontal growth) and can continue to roll out additional complementary features (vertical growth). TL;DR: grow horizontally first—as many customers as you can identify that need to function your API delivers, then vertically—finding the next adjacent function and trying to deliver that within the industry verticals you’ve penetrated.

Fifth, API-first strategies place a premium on distribution and channel utilization. So, while implementation costs shrink (users can basically implement it themselves), and repeatability increases, the reliance on partners and channels plays a greater overall role because the technology is highly portable. An API-first company will make money wherever it's implemented by its own users—low cost, high repeatability.

Ask yourself this: can you count how many times this holiday season you bought something online and paid via paypal or stripe? And though these companies both have robust APIs, I bet you knew when you were paying with PayPal but not necessarily paying with Stripe.

Finally, sufficiently-sophisticated APIs, when implemented, create hard-to-reproduce datasets (remember that thing about moats?). Most importantly, the robustness of an API, combined with its usage, is positively correlated with data exhaust, that wonderful byproduct that goes into creating value-add proprietary datasets. In fact, the strongest-performing API-first companies are masters of exploiting this trait—in macroeconomic terms, you might think of this as an increasing marginal product of capital. As a result, an API-first company is uniquely positioned to maximize their users' chances of developing proprietary data sets and features— recommendations, modeling and predictions, risk scores, price transparency, process metadata etc.

In the next section we'll walk through an example of how this has played out historically between vendor and buyer before turning to the practical impacts these forces have on traditional banks and nontraditional financial applications.

[1] One may consider this the external ramification of tech debt—rather than legacy tech holding back development, this is legacy tech holds back the capacity to clear a market.

**

Amias Gerety is a partner at QED Investors, a leading fintech venture capital firm.  His investing has focused largely on back office and infrastructure themes.  Prior to QED, Amias was Acting Assistant Secretary for Financial Institutions in the Obama Administration.

Nate Soffio is an MBA Candidate at Wharton focusing on fintech, regulation, and financial inclusion. There, is the co-chair of Wharton’s Fintech Conference taking place April 22-23. Hailing from Stamford, CT by way of Medellin, Colombia, he spent a decade building (and breaking) things in the infrastructure and regtech worlds with a focus on Know-Your-Customer and identity management. Before Wharton, he helped lead product at Arachnys, a London-based regtech and QED portfolio company. Nate holds a B.A. with Distinction in Linguistic Anthropology from Yale University.  In his spare time you can find him road cycling, rock climbing, and cooking.

Media inquiries:

Ashley Marshall, Director PR and Communications, QED
Ashley@QEDInvestors.com
(518) 577-9984