APIs All the Way Down (Audio)

Welcome to the 1,367 newly Not Boring people who have joined us since last Monday! If you’re reading this but haven’t subscribed, join 23,341 smart, curious folks by subscribing here!

Today’s Not Boring is brought to you by…

In September, I wrote about MainStreet, a company that literally just gets your company free money from the government. Since then, Main Street has found Not Boring readers $1.1 million in sweet sweet free government money. $1.1 million! It’s simple, you plug in your payroll, MainStreet finds tax credits and incentives that apply to your business, then they send you the money. Like I said, free money.

On average, MainStreet finds companies around $50k. That’s a lot of holiday bonuses. If you work for a company in the US that has engineers, go, right now, and get your money.

Hi friends 👋 ,

Happy Monday! Most weeks, as I’m researching and writing and preparing to hit send, I feel like a total imposter.

Sometimes, like when I’m writing about the future of the office or Slack, topics that I’ve spent years thinking about, working in, and using, I’m comfortable that I know what I’m talking about and am qualified to opine. But mostly, I’m dropping into new territory and writing thousands of words about industries and companies in which other people have spent most of their working lives. When the topic is technical, I feel it even more.

This week’s topic - APIs - is among the most imposter syndrome-inducing yet. On the one hand, it feels like I’m stating the obvious: APIs are an increasingly important piece of how software is built. On the other, I feel like I have nowhere near the technical depth or hands-on experience to write about the topic with the nuance it deserves.

But in these cases, I view my role as being the shameless kid in class who’s not afraid to raise his hand and ask the question that everyone else is thinking. If there’s something happening that I know is important, but don’t know nearly enough about, and I do this for a living, chances are there are many of you who want to understand it a little bit better, too. This, then, is the beginning of an exploration, and I look forward to your thoughts and feedback.

Now let’s get to it.

APIs All the Way Down

Some ancient Asian cosmological views are close to the idea of an infinite regression of causes, as exemplified in the following apocryphal story: A Western traveler encountering an Oriental philosopher asks him to describe the nature of the world: “It is a great ball resting on the flat back of the world turtle.” “Ah yes, but what does the world turtle stand on?” “On the back of a still larger turtle.” “Yes, but what does he stand on?” “A very perceptive question. But it’s no use, mister; it’s turtles all the way down.”

-- Carl Sagan, Gott and the Turtles

Stripetechery

On Thursday, the kind of thing that gets people like me very excited happened: Ben Thompson wrote about Stripe, which announced its new Stripe Treasury product, and interviewed its co-founder and President, John Collison. 

Stripe Treasury is “a banking-as-a-service API that lets you embed financial services in your marketplace or platform.” Simply, by writing a few lines of code, platforms can let their customers set up bank accounts at partner banks like Goldman Sachs and Evolve Bank & Trust. 

In the press release, Stripe highlighted its partnership with Shopify, which is using Treasury to build Shopify Balance. Now, when a merchant creates a Shopify account, they can set up a bank account at the same time, through the same platform. 

That’s incredibly cool in its own right, but it triggered bells in my head for another reason. When I was researching and writing Stripe: The Internet’s Most Undervalued Company, I asked people for the biggest knocks on Stripe. One answer I heard from multiple people was that they had too much customer concentration with Shopify -- by one estimate, even before the pandemic, Stripe was generating $350 million in revenue from Shopify alone -- and that Shopify would inevitably get sick of paying Stripe and build their own payments solutions. 

The Shopify Balance announcement means that the opposite is true. Instead of pulling its business, Shopify is integrating more deeply with Stripe. Many of its clients will keep their money in accounts managed by banks with which Stripe, not Shopify or the merchant, owns the relationship. Think of the switching costs if Shopify were to try to pull out of the relationship now. They’re practically married.

Shopify is a really smart company. It wouldn’t tie its own hands for no good reason. Instead, it made a deliberate, strategic choice to focus on the things that it does best, and to plug in Stripe for all of the things that it does best. That’s what third-party APIs enable their customers to do. 

“API” is one of those acronyms you hear a lot. You might know that it means Application Programming Interface, and you might even know that APIs are the way software talks to other software, but if you’re like me, you’ve never really gone deep on them.

The Stripe x Shopify announcement woke me up, though, and led me down a rabbit hole to places both familiar and new, to the question of what good strategy looks like on the internet and why most companies should just be API Frankensteins with one main point of differentiation. Like the turtles, modern software is APIs all the way down.

So today, I’m going to take you down there with me. We’ll explore: 

* What Are APIs?

* The API-First Ecosystem

* Good Internet Strategy, Bad Internet Strategy

* Why Shopify is Smart to Build on Stripe and Twilio

* The Magic of API-First Business Models

* Twilio and Investing in API-First

API-first has some fascinating implications for how companies are built and where value is created. But first things first… 

What Are APIs? 

There’s an old Picasso fable that goes something like this: 

A woman approaches Picasso in a restaurant, asks him to sketch something on a napkin for her, and tells him that she’d be happy to pay whatever it’s worth. He obliges, scribbles something quickly, and asks for $10,000. “$10,000!?” the woman replies in shock, “But you just did that in 30 seconds!” “No,” Picasso tells the woman, “It has taken me 40 years to do that.”

That’s one way to think about an API. APIs let companies leverage years of other companies’ work in seconds. 

For a more technical but approachable explanation, Justin Gage’s What’s an API? and APIs For the REST of Us are the two best resources I’ve found. According to Justin:

Applications are just a bunch of functions that get things done: APIs wrap those functions in easy to use interfaces so you can work with them without being an expert.

An engineer writes a bunch of code to manage complex things, and builds an API on top of the code to abstract away most of the complexity so that using all of that code is as simple as writing a few lines of code.

On Invest Like the Best, Benchmark’s Eric Vishria describes it simply: people interact with software through Graphical User Interfaces (GUIs), software interacts with software through APIs. 

APIs handle an ever-increasing amount of things that get done in the world. Something that might have been a pen and paper process involving hundreds of people 50 years ago, and a dozen people clicking a computer screen a decade ago, is probably software talking to other software via APIs today. 

There are three types of APIs: 

* Internal APIs: Used to do complex things more simply within a company. 

* Public APIs: Typically used to open up datasets so the public can build on top of them. 

* Vendor APIs: Give customers the full superpowers of an entire company in a few lines of code.

Today, we’re focusing on Vendor APIs, also known as third-party APIs. The companies who sell third-party APIs are called “API-first companies” (still with me?). 

Whereas an internal or public API abstracts away the complexity of some code through one clean endpoint, like this: 

An API-first company essentially abstracts away the complexity of a whole best-in-class company, giving clients the full output of a highly-focused org by typing a few things, like this: 

Hiring has traditionally been one of the most important things a company does. Picking the right API vendor is like the hiring decision on steroids. When a company chooses to plug in a third-party API, it’s essentially deciding to hire that entire company to handle a whole function within its business. Imagine copying in some code and getting the Collison brothers to run your Finance team. Just like in traditional hiring, the impact of that decision compounds over time, for better or for worse, but at full company scale.

So let’s get to know the job candidates. 

The API-First Ecosystem 

API-first companies are a subset of Software-as-a-Service (SaaS) companies, with a few key distinguishing features: 

* Purchasing Decision. Traditional SaaS is a department-head, IT, or exec purchasing decision, while API-first is typically a product and engineering purchasing decision. 

* Users. Many people in a company interact with a typical SaaS product (like Slack, Salesforce, Airtable, Asana), whereas only the engineers typically work with API-first companies.

* Business Model. The most common SaaS business model is to charge per seat, while most API-first companies charge customers by usage of the product, either based on Pay Per Call (each time the API is pinged, say if you’re sending an SMS via Twilio) or as a percentage of transaction size (Stripe charges 2.9% plus $0.30 for each transaction). 

* Use Case. Traditional SaaS products help employees get things done, APIs automatically do those things themselves. 

API-first companies can be confusing to explain, because many of them offer both API products and traditional SaaS products. Their customers run the gamut, from large platforms like Shopify and Uber all the way down to individuals who want to accept payments online, and everything in between. Puja and I just had pictures taken with Dev, and the photographer sent us her invoice via Stripe. She was using one of Stripe’s traditional SaaS products with a GUI, not writing code. 

For this essay, though, we’ll be talking about API-first companies whose customers build functionality into their products or internal processes via APIs. 

Those companies are increasingly able to build nearly everything non-core through APIs. In The Third-Party API Economy, Canvas Ventures’ Grace Isford maps dozens of players in the space across nineteen separate verticals. 

“There’s an app for that” is now “there’s an API for that.” For almost anything that a business needs to do, there’s an API-first company with a product or suite of products they can plug in. What’s incredible to me about this graphic is that each logo represents something that a company would have had to build on its own previously, that it can now do by writing a few lines of code, and do better than they would have ever been able to in-house. 

There are two main reasons for that: focus and scale. 

Focus. API-first companies focus on solving a very specific problem. Stripe started with payments, and put all of their efforts into building the best payments solution. Twilio started with messaging and calling. Plaid does bank data, Algolia does search, Shippo does shipping, Checkr does background checks. That focus means that everything the company does is oriented towards solving all of the problems related to that particular area. 

Importantly, it means that everyone who works for those companies went there to solve those problems. Whereas an engineer at Uber who signed up to change transportation would be pissed off if she were assigned to work on background checks, because it’s not the company’s core product, an engineer at Checkr is stoked to work on background checks, because that’s what the company is all about! 

Scale. API-first companies serve thousands or millions of customers, so they’re able to justify small improvements that build up to an incredible product over time. Plaid can spend the effort to integrate with even very small financial institutions, for example, since there will likely be thousands of people who use that bank across all of the products that use Plaid. 

API-first companies’ focus and scale give their software-building customers best-in-class products that constantly improve at costs that scale with their business. From the product side, they can be godsends. They’re also fascinating strategically in two ways: the competitive advantages of the API-first companies themselves and the impact they have on their customers’ competitive advantages. Let’s start with their customers. 

Good Internet Strategy, Bad Internet Strategy

While I write more often about 7 Powers and The Outsiders, Richard Rumelt’s Good Strategy, Bad Strategy is probably my favorite practical strategy handbook ever written. 

Good strategy almost always looks simple and obvious and does not take a thick deck of Powerpoint slides to explain. It does not pop out of some “strategic management” tool, matrix, chart, triangle, or fill-in-the-blanks scheme. Instead, a talented leader identifies the one or two critical issues in the situation — and then focuses and concentrates action and resources on them.

This is the beauty of API-first companies. They allow customers to focus on the one or two things that differentiate their businesses, while plugging in best-in-class solutions everywhere else. Just as AWS and the cloud let entrepreneurs launch more cheaply, API-first businesses allow them to scale and professionalize with low upfront costs and managerial effort. As one person in the space told me, “It’s actually becoming crazy to build your business in any way other than using all APIs except your point of differentiation.”

Jeff Lawson, the founder and CEO of leading API-first company, Twilio, might disagree with the premise of talking strategy at all. On the Bessemer Venture Partners Cloud Giants Podcast, he said: 

I often say that strategy is a dirty word in business; it should be struck. Any time you find yourself talking about strategy, you’re probably off-course, actually. There’s only one business strategy: serve your customers. 

I don’t think that Rumelt and Lawson would disagree, actually. Both point at the same idea, that what people call “strategy” is often a bunch of fancy words and falsely precise goals that obfuscate the core purpose of the business: serving customers in a differentiated way. Judiciously using APIs where possible gives companies strategic clarity and the ability to solve their customers’ problems in a way that only they can. 

Identifying the “one or two critical issues” (Diagnosis) is just one piece of the problem. Good Strategy also involves defining a guiding policy and coherent actions.

A guiding policy “outlines an overall approach for overcoming the obstacles highlighted by the diagnosis and tackles the obstacles identified in the diagnosis by creating or drawing upon sources of advantage.” It channels a company’s energy towards the areas where it has unique advantages.

Coherent actions are the set of interconnected things that a company does to carry out the guiding policy, each reinforcing the other to build a chain-link system that is nearly impossible to replicate.  Walmart isn’t the leading retailer because it has lower prices, or because it puts its stores in a certain type of town, or because it’s built up the right distribution network, or because of any single thing that it does. It’s the leading retailer because all of those pieces work together in such a way that no one could copy Walmart without copying the whole system.

If Lawson will indulge me, there are actually some pretty wild strategic implications to coherent actions in an API-first ecosystem, in which the traditional conveyor belt-style value chain model no longer makes sense. 

Traditionally, the coherent actions taken by a company would look something like Michael Porter’s Value Chain, which we discussed at length in Shopify and the Hard Thing About Easy Things. In 1985, Porter wrote:

“Competitive advantage cannot be understood by looking at a firm as a whole. It stems from the many discrete activities a firm performs in designing, producing, marketing, delivering, and supporting its product."

Those discrete activities comprise a company’s value chain (although Rumelt might bristle at the word discrete and focus more on the links between activities). The Direct-to-Consumer Value Chain, for example, looks something like this (sans Support Activities):

It’s clean and linear, like a pipeline. R&D leads to manufacturing, and so on. 

But in a world in which APIs infiltrate ever more functions of a business, the linear value chain no longer perfectly describes a company’s activities. Chris Sperandio, now at Stripe, wrote a piece while at Segment arguing that there needs to be a new, more dynamic model of a firm: the “Request/Response” model. 

In the essay on Shopify, I wrote: 

Here’s the hard thing about easy things: if everyone can do something, there’s no advantage to doing it, but you still have to do it anyway just to keep up. 

That applies to the DTC Value Chain, and to some extent, it applies to software and platform businesses building with many of the same APIs. If your competitor is using Twilio to send SMS to clients, you should, too, or else they’re free to build differentiated products while you spin your wheels reinventing the wheel. In the Request/Response Model, though, there is also a competitive advantage to be gained from how you leverage APIs to build your company and product. 

Using a bunch of APIs that are really flexible, and figuring out good ways to connect them, leads to a combinatorial explosion of potential workflows. API-first companies turn software into like customizable building blocks, and companies like Zapier and Tray.io function as “APIs for all APIs,” making connections between nearly any app with an API fast and easy.

Not only can you put the building blocks together in unique ways (the “Infrastructure” column in the Request/Response model), but you can also build new experiences on top of them (the “Operations” and “Experience” columns in the Request/Response model).

If the number of potential connections between APIs increases exponentially as more are added, companies have a near-infinite ability to create unique chain-link systems of coherent actions out of the existing primitives. Instead of a linear value chain in which using commoditized components in each step limits the number of places left to differentiate and create value, the Request/Response Model lets companies differentiate on two main fronts: 

* Direct. The core focus area, for which they build their own solutions. 

* Meta. The way that they organize all of the components in their ecosystem. 

That creates a dynamic system in place of a static chain, one that constantly improves and evolves as the companies behind each one of the components work on building the best possible input for their customers. 

So Why Does Shopify Rely So Heavily on Stripe?

Which brings us back to why Shopify works so closely with Stripe, even though they paid an estimated $350 million for the privilege even before their pandemic-fueled growth, and why they continue to strengthen the partnership. It’s just good strategy. Shopify focuses on its key differentiators and building a coherent whole that is differentiated even while many of the components are modularized.

Stripe is the prototypical API-first company. It does a whole lot of complicated things behind the scenes, and offers it to customers in a few lines of code that abstract away all of the complexity. When a company chooses to use Stripe Payments, it copies in those few lines of code and sits back while Stripe pushes updates to its core API 16 times per day. It lowers fraud, improves acceptance rates, accepts payments from more countries, pushes faster payouts, and does countless other little things that improve the payments piece of their customers’ businesses. That translates into more money over time, with no extra effort.

And it’s not just Payments. It’s Treasury, Subscriptions, Billing, and Corporate Cards. The products it offers customers seemingly grow by the day as it leverages its work in one area to expand into adjacent areas with the goal of “Increasing the GDP of the Internet.” Two days before launching Stripe Treasury, for example, Patrick Collison announced Stripe Capital for Platforms, which lets platforms like Shopify lend money to their customers, again, by writing a few lines of code. 

By working with Stripe, Shopify gave its customers the power to seamlessly collect payments, then to easily manage subscriptions, then to borrow money, and now to launch bank accounts in a few clicks. Shopify is able to build products in months that would otherwise take years, and even then, wouldn’t match what Stripe is able to do given its unique focus and all of the hard, non-technical, regulator-and-bank-related work it does behind the scenes.

In that sense, the Stripe x Shopify partnership is like an API in itself. Shopify plugs in Stripe, and Stripe continues to add new money-related products that Shopify can use itself and give to its customers. 

The better each Stripe product gets, and the more great products it offers, the less likely Shopify is to ever leave. And why would it? Instead of hiring armies of engineers and spending management brainpower on a second-class product outside of its core competency, it can pay Stripe to handle all of that. Stripe can build robust money-related solutions for Shopify at a lower cost than Shopify could build for itself, because Stripe is able to amortize the costs of everything that it builds over millions of customers, some large and many small. 

Lest you worry about Shopify’s dependence, though, while Thompson’s graphic shows Shopify as just one of many potential Stripe customers, Stripe is also just one of many third-party APIs that Shopify uses. When Twilio talks about its Flex product, for example, it uses Shopify as a case study. Flex, Twilio’s call center API, lets Shopify build customer experience solutions that it only dreamed of before, because Twilio has spent a dozen years and hundreds of millions of dollars creating all of the building blocks that Shopify’s team can use to design new solutions in minutes. 

As I was talking to my friend Ben Rollert, who’s building a company on top of APIs, he said that the value system in an API-first world actually looks more like the game Factorio than a traditional Porter Value chain. 

It’s probably not a coincidence that Factorio is one of Shopify CEO Tobi Lutke’s favorite video games, and the one game that he lets every employee expense. Uncoincidentally, Shopify is the low-key leader in building a business using APIs wherever possible in order to focus on its unique point of differentiation: building best-in-class digital eCommerce solutions. 

Just two weeks ago, for example, Shopify launched Handshake, a wholesale marketplace it acquired last year in order to compete with unicorn startup, Faire. Giving Shopify merchants access to more inventory at better terms all in one place is core to what Shopify does, and it takes advantage of the scale benefits that Shopify itself has, bringing demand from millions of retailers to bear on wholesale negotiations. 

Strategy is about knowing when to say no, so that when you say yes, you can go all-in. Because Shopify spends less time on non-core things, it’s able to increase its product velocity on the things that really matter to its customers. 

The Magic of API-First Business Models

Now how about the API-first businesses themselves? 

Strong API-first businesses sit in this sweet spot: they provide mission critical but non-core functionality to their customers, like accepting payments, providing cloud security, or sending communications to customers. 

That means two things: 

* Massive Markets. API-first companies each provide a small slice of the things every business needs to do. Almost every company needs to collect money, remain secure, and communicate with customers. 

* Moats. They’re in a position in which companies can’t just rip them out -- imagine not accepting payments for even a day! -- but where it’s probably not worth the resources or defocusing to build a different solution in-house. 

Shopify’s increasing dependence on Stripe and Twilio also points to the importance of that position. And it’s not just Shopify. Facebook’s WhatsApp pays Twilio $100mm per year for account verification. 

One of the most common refrains that API-first businesses hear is, “Oh Company X will just build that in-house,” and yet, they almost never do. It’s not for lack of resources. Facebook generated more profit in 2019 ($57 billion) than Twilio’s entire market cap ($51 billion). It’s that once they’re integrated into a customer’s product, API-first companies have incredibly deep moats. Specifically, they benefit from network effects, economies of scale, and high switching costs. 

Network Effects

The best API-first businesses have data network effects: the more customers that use the product, the better the product gets for each customer, because the API-first business can use data from one customer to improve the product for all of them. For example, every time a company uses Checkr to run a background check on someone, Checkr gets data on that person that it can use to benefit the next company who wants to hire them and it can pick up patterns across millions of people that allow it to perform more accurate checks more quickly and cheaply.

Additionally, API-first companies that negotiate with third-parties on their customers’ behalf -- Stripe with credit card companies on fees, Shippo with FedEx and UPS on shipping rates, Twilio with carriers on messaging fees -- can bring the heft of their collective bargaining power to the table for their customers in a way that none of them could on their own. 

Economies of Scale 

API-first companies have scale economies advantages not just over new entrants, but more importantly, over their own customers who might consider just building the functionality in-house. Since they focus on one category and amortize their development costs over thousands or millions of customers, they’re able to build for all of the little edge cases that add up to big advantages. Twilio has relationships and contracts with every phone carrier and telco across the world, meaning that a customer can just plug them in and expect to get their messages delivered or their calls completed anywhere their customers may be. It would make practically zero sense for any one company not focused on the space to negotiate all of those deals for themselves, and even if they did, they wouldn’t have the same bargaining power Twilio does. 

Switching Costs

Remember, one of the main reasons that companies use API-first products is that doing so gives them peace of mind that that slice of their business is in good hands so that they can focus on their own points of differentiation. Even if a company thinks it can save a little money or get a slightly better experience by switching vendors, doing so requires prioritizing that work over the countless things on the roadmap that are core to what the business does. 

Since most API products are building blocks that customers can use to create their own custom solutions and workflows, moreover, switching costs increase as customers build on top of APIs. 

Additionally, as an API-first company adds more functionality and products, as Stripe has done with both the Payments product and new products like Treasury, customers become more locked in. This is particularly true if an end user stores anything -- from money to data -- with the API-first company’s products. If a company needs to ask its customers to do something in order to continue using the service as usual, it will likely be too worried about churn or inaction to switch. 

This indirect relationship with the end user points to another advantage of the API-first business model: customer-led growth. In Slack: The Bulls Are Typing…, we talked about the fact that Slack sold into companies and then grew as they grew headcount. API-first companies have a model that’s potentially even more powerful. Once they convince a customer to embed their code, the onus is on the customer to grow their own customer base. That means that all of the Facebook and Google dollars fall on the customer, and that as they spend money to grow, the API-first company goes along for the ride. 

There are a few challenges and risks to the API-first business model, though: 

* Margins may be lower than traditional SaaS businesses. Many traditional SaaS products benefit from the “high upfront costs, low marginal costs” nature of software. APIs, on the other hand, often put a nice wrapper on top of existing products that come with their own costs. Stripe still has to pay credit card processing fees, for example, while Twilio has to pay carriers to send messages and make calls. API-first companies are typically lower-margin, higher-volume products. 

* Other API-first companies are coming after your place in the stack. The most valuable place in the API stack is to be right between your customer and all of their other vendors, abstracting away the complexity created by the other companies abstracting away complexity below them. Segment, for example, which Twilio recently acquired, is a Customer Data Platform that ingests all of the data that a company's other vendors create about its customers. It controls the customer relationship and modularizes the other APIs below it. 

That leads to one of the most important things to realize about API-first companies: they’re a lot more than just software. Anything that just takes complex code and simplifies it is probably at risk of being upstreamed by competitors or new entrants. The magic of companies like Stripe and Twilio is that in addition to elegant software, they do the schlep work in the real world that other people don’t want to do. Stripe does software plus compliance, regulatory, risk, and bank partnerships. Twilio does software plus carrier and telco deals across the world, deliverability optimization, and unification of all customer communication touchpoints.

Getting the benefit of all of that grunt work in a few lines of code is why customers sign up for API-first products and stick with them, even as their bills balloon. 

Twilio and Investing in API-First

“APIs give their customers superpowers.” That’s the phrase you see most often when researching the space and talking to people in it. It’s also how I felt when I found Twilio. 

My first exposure to the wonderful world of third-party APIs came six years ago, in my first few months at Breather. The most important part of my job as the first and only employee in New York City was convincing landlords to lease us space in their buildings, which we would then re-rent to strangers. It was a predictably hard sell, and I heard “no” more times than I care to remember. Then, after weeks of no’s, one landlord on East 27th Street said “yes.” There was only one problem: instead of a doorman, the building had a keypad that dialed out so that tenants could buzz in their guests. Given the fact that we had no one on site, our options were: 

* Send someone to the building with a key for every reservation.

* Turn down the lease. 

* Get creative and figure something out. 

I chose C, and spent days googling derivations of “remote access building” and “unlock door building phone.” All of the solutions required installing hardware, which was a non-starter. And then I found Twilio. 

In the course of a couple of hours at a company Hackathon, I set up a Twilio account, got a custom phone number, asked the landlord to program the box to call that number, and wrote a script that played the DTMF tone that would unlock the door for our clients. I even recorded a message -- “Hi, welcome to Breather!” -- that played every time someone gained access. Then I took a subway up to 27th street, entered our suite number on the keypad, and held my breath. Five seconds later, I heard a click, and the door unlocked. I felt like a fucking wizard. 

Twilio gave me superpowers, which I used to sign leases on a whole swath of buildings that were previously inaccessible. A couple lines of code changed the course of the business. 

You would think, then, that when Twilio went public on June 23, 2016, I would have bought it on the first day. And you would be wrong. I ignored it, dismissing the company as a toy that let me unlock doors. That was a mistake. 

Since its June 2016 IPO, Twilio is up a casual 1,115%. Over the past year, it’s grown 222%, outperforming the BVP Emerging Cloud Index by 2.4x. 

Despite missing most of the runup, I’m still bullish on Twilio’s future and started a small position in the company that I plan to add to over time. There are a few reasons: 

* The API-First Business Model. For all of the reasons highlighted above, I’m a fan of the API-first business model. Twilio has a large and growing customer base and is able to cross-sell new products like Flex and SendGrid in a Stripe-like “Company-as-an-API” model. I love it when a hypothesis plays out in the numbers, and in this case, Twilio’s moats translate into a BVP Emerging Cloud Index-leading 137% Net Dollar Expansion.

* Segment Acquisition. In October, Twilio announced that it was acquiring Segment, the leading customer data platform in a valuable position on top of many other API-first companies in the stack. In an interview with Ben Thompson, Lawson explained the deal by saying that to build a customer relationship, you need understanding and engagement. Twilio provided engagement, Segment brings the understanding. Thompson hypothesized that this could be the beginning of an ad product that could compete with Google and Facebook. If that’s the case, the opportunity is multiples of Twilio’s current market cap. Even without that mega-bull case, the two companies have an estimated $79 billion market to attack, and Twilio plans to use its relationships with developers to go after it. 

* Segment took a $3.2 Billion All-Stock Deal. Segment was one of the hottest API-first companies in the market, sitting in a plum position in the stack, and it chose to sell its company for all Twilio stock (which is down slightly since the day of the announcement). I trust that Segment had a good reason for its decision.

* Developer Focused, API-First Juggernaut. When the Segment deal was announced, friend of Not Boring Logan Bartlett, a SaaS-focused VC at Redpoint Ventures tweeted:

Twilio can become the leading acquirer in the API-first ecosystem and expand the building blocks it gives companies to build on top of. The API-first market map will become competitive M&A territory, and Twilio has shown that its unique combination of size and developer love, rivaled only by Stripe, is attractive to potential targets. 

These are just some rough thoughts (and obviously not investment advice). Twilio deserves a deep dive of its own. Luckily, investing in a company is my favorite way to force myself to get smart on an industry, and API-first feels like one that has a lot more to uncover. More doors to unlock, if you will. 

Thanks as always to Dan and Puja for editing, and to Ben and my other more technical friends for the input and ideas!

Just a few more things. Last week was a whirlwind of fun conversations and collaborations, check ‘em out:

* Acquired Slack x Salesforce Podcast :Acquired has been one of my must-listen podcasts for a few years, and their work is the starting point for a lot of my essays (including Tencent and SoftBank). It was surreal and so much fun to be able to join David and Ben to talk about Salesforce’s acquisition of Slack.

* S-1 Club: Airbnb: It’s finally here. Airbnb is going public this week (rumored to be pricing at a $42 billion market cap). I teamed up with Mario Gabriele and the S-1 Club to go deeeeep on the company in preparation.

* Remote Work Conversation with Paul Millerd: Last week, I wrote about Remote Work. My friend Paul Millerd has been living the remote life since before it was cool, quitting his job at a top-tier consulting firm to go solo. Really fun convo.

Thanks for listening, and see you on Thursday,

Packy

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit www.notboring.co