How APIs are Changing Modern Development with Sendbird

All right, hello everyone. I hope everyone's settling in. It's good to meet you all. I'm John, founder and CEO of Sendbird. So just to give you a quick intro or brief background on what we do, Sendbird, we are the world's number one chat API. We power in-app chat, voice and video calling over IP, and today we power over 200 million people who have conversations through our API system on a monthly basis. And then we also recently announced our $100 million Series C about a quarter ago, putting our company a little bit above a billion dollar in valuation. So it's kind of what we do. But today we want to talk a little bit about how APIs can help modern software development as well as accelerating your product velocity. So before we start, let's do a quick poll. Like, how would you describe your organization's engineering culture today? There's software engineering organization where you're really focusing a lot on your core and then probably proactively buying a lot of software from the outside vendors. And there's some companies who are trying to figure out like, which do we build, which do we like own internally versus working with third-party vendors. And then lastly, there's still a lot of organizations today who want to build as much as possible internally and then really own that IP and then have a tighter control on, on your software. Environment. So love to get a quick sense. Seems like the results are already coming in. Quite interesting. So, um, seems like a lot of the answers are kind of half-half, close to like buy some, build some. And still a lot of the organization seems to be buying or building internally as much as possible, which is very interesting to see. So with that context in mind, let's, um, we'll dive right in. So I've been a software engineer by trade, and I've been building product and engineering organizations, and then also being a founder CEO of two different startups over the past, I guess, close to 15 years or so. And I wish this were true, but I've never been in a situation where everyone was like so excited about how the product velocity is accelerating, or where we had abundance of engineering resources, or there was any case where we felt like Oh, hiring engineers and retaining engineers are a walk in the park. It's so easy. That unfortunately has never— I unfortunately have never been able to experience that. And I thought it would change when we announced our kind of so-called unicorn round. The resumes were starting to flowing in and hiring key engineers gets a lot easier. Well, yes, the resumes do increase, but just hiring and retaining talented engineers have always been one of the toughest challenges. As a leader of the organization. So then how do we kind of solve this, right? And I come from this like the old school of where as a software engineer, I want to build everything myself. I want to have a tight control over my own software and also really own the IP and then having full visibility and autonomy over the software and the user experience we want to build. But over the past, I guess, decade or so, I came to realize that it's no longer really about having visibility and tight control over your entire code base. What's really more important is how do we accelerate the product velocity and accelerate the learning as an organization by, you know, experimenting with the market, iterating the product as quickly as possible, and leveraging proven technology to actually go to market faster. Because it's like, I think my technical co-founder said it best, it's half production, half promotion. You really want to go to market faster and learn. And to do that, nowadays we have like abundance of API technologies that we can leverage to go to market faster, which also offers, uh, greater flexibility and higher quality given it's, uh, um, that it has a lot of proven points working with other, uh, customers as well. So, uh, I think Apple said it the best. There's an app for that. Also for software engineers, there are APIs for that. Today, there are a lot of, uh, components of software that we can work and APIs that are available widely in the market today that deals with like user authentication and identity, your payments and translation, SMS, and so forth. And there are abundance of, I guess, APIs that can really help you accelerate product roadmap faster. And then a lot of, as you can see, a lot of the features are used by pretty much all the applications out there. So the more common software components there are, these tend to become massive, massive companies. So we already know like Okta, we use them ourselves for identity, identity authentication, Stripe for payments. So there are a lot of vendors you see here are what we also use internally to build our own software. And we're part of this ecosystem, so-called the API economy, where you can really, you know, use and pull different parts of the API and plug into your software to again go to market faster with higher quality. So the world has shifted from builders building everything themselves, hacking together different open sources to really assembling new and different, different experience that are unique to your own business by leveraging proven technologies that so that you can go to market much, much faster. And kind of taking a step back, you know, what does it mean? If you look at any kind of an industry that's big enough and has evolved over a long period of time, usually a lot of the industry initially started out pretty much, you know, very small with everyone kind of doing everything under the roof. Then the ecosystem kind of evolves where there are multiple different organizations that are kind of all contributing to develop different parts of value chain. And then ultimately, as the industry becomes large enough, companies really tend to focus on what's unique and, and core to their business, and then working with the other parties in the ecosystem. And I'm kind of borrowing this slide from Andreessen Horowitz's comparison on the API economy. If you look at the automotive industry, back in the 1920s when Ford Motors and other companies kind of started to come out, they really owned the entire ecosystem or the value chain of car production as well as selling. So a lot of these car manufacturers would intake the ingredients or the raw materials to build out the components of the cars, as well as the full production and manufacturing, and then also going to the market with it. The companies tend to own the entire value chain. But of course, we know over the years, the automotive industry has gotten so complex, so large, that there's a lot of companies that are worth billions and billions of dollars just focusing on one single component of cars, whether it be brakes, tires, and whatnot. And each of these vendors have, have a place in the ecosystem where they are now contributing to this massive, massive industry. And as we're seeing something very, very similar happening in the software industry as well. So what's really happening as this kind of industry evolved is that initially when companies start out, there is no ecosystem. You're kind of doing everything. You're getting the raw materials, manufacturing them, shipping them, selling them, all those things. So basically you have put your entire company at risk by risking the different parts of the value chain. But as the, again, the ecosystem evolves, each company's trying to figure out what, what are they really good at and how can they contribute to the rest of the ecosystem. And then the companies kind of figure out their own position in the ecosystem where they can really capitalize on their own strength. And they're relying on other companies' strength to really, you know, build out the ecosystem together and then actually create a differentiated value for the market. And again, same thing is happening with software. Initially, again, as a software engineer, you know, maybe a couple of decades ago, we used to write everything, whether it be using C or whatnot, used to write every single part of the code. Nowadays, of course, their APIs are open sources. So companies have evolved to start outsourcing the parts of the software to whether it be open sources or some outsourcing firms. But then more recently, we're now leveraging a lot of software that are running on cloud APIs, the SaaS products. So we're starting to spend more and more of our product and engineering resources really focusing on the core and then relying on the rest of the ecosystem to go to market faster again with higher quality. So that's kind of pretty much similar with all the industries that have evolved, uh, sophisticated, uh, over the, um, couple of decades. So you can think of APIs not just as a tool for software development. It's actually a way to manage your risk of your business. Which part do you, uh, take risks in by, um, you know, creating your own unique, uh, differentiated value for your own, uh, software? And then which are the parts you feel is, uh, is common enough where you can kind of start borrowing from different parts of the ecosystem to de-risk your business. And be able to go to market faster. So a quick and dirty kind of checklist to figure out whether you want to use an API for your software or not is, uh, there are a couple of lists that we like to look at. One is, is this technology hard or messy to, you know, get it right? Uh, there are of course things that are really, really unique and core to your business where you don't want to like rely on third-party vendors, but there are some commonalities or components that you feel is kind of universal enough that you want to kind of be able to plug in and not deal with the mess or the, or the difficulty, that's where you just start look elsewhere and look at the other API vendors. Second is when kind of everybody has it, right? The ecosystem has taken that this is here to stay, this kind of user experience or technology is here to stay. So it's kind of universal at this point, to a point where it's become a commodity where you don't want to kind of reinvent the wheel. Third, from the end user or your customer's perspective, the user experiences become also became so universal that people kind of take it for granted. If you don't have it, people are kind of disappointed. Or when, even if you do have it, there are certain expectations they have around the user experience where you have to meet, otherwise just people will find it very, very disappointing. And I think these, in the management world, this is called the hygiene factor, where if you don't have it, people just go away and you just have to have it. But even if you have it, it doesn't really create a differentiating factor for your business. That's kind of when you know you have to start, you know, look at, look at the ecosystem of APIs. And then also from the user experience or software development perspective, this is something that should just work. And if you think about any hardware massive problems, there are a lot of edge cases. So can this technology really create an abstraction layer so that it just takes rid of all the edge cases or those kind of missing bits and greases? It should just plug plug in and just, just should work very, very smoothly. And the fifth is that the, the area of this API is quite important for your business, but again, it's not the main differentiator or something that creates a unique value for our own product. That's an area that you want to kind of rely on outside vendors. And then lastly, we kind of talked about this in the earlier part of the slide. How can you actually go to market faster so that you can iterate faster, learn much faster with the feedback from the market? And if the speed of go-to-market, going to market fast, going fast is important for your business, that's when you know you have to start thinking about leveraging outside APIs. So these are kind of the quick and dirty list of thinking about what are the things you want to use APIs versus what are the things that you want to kind of own and build it yourself. So just to give a couple of examples, Kip Trucking, a very massively successful company, have been using our are and/or have been leveraging APIs to manage the advanced fleet management. So the focus is keeping the truck drivers safe, compliant, and efficient on the road. And as you can see, they've been leveraging different kinds of APIs to really build out their product, and they've also used Sendbird to power their communication for the fleet management. Second is the Doc Planner. Doc Planner makes it easier for patients to kind of locate and book appointments for free with doctors based on their location, as well as their, their online reviews. And again, they've been leveraging different kinds of APIs, whether it be locations or calendar sync using Chronofy to book appointments, but also have been using Sendbird to power their communication piece for planning purposes. And also Hinge has been one of our long-term customers, part of their match, part of the match group, have been using Sendbird to power their chat piece. And what's interesting about Hinge is they've actually started with their own in-house chat solution. But over the years, as they continue to scale and grow, they kind of realize, okay, chat is kind of a common piece where you don't want to reinvent the wheel. Chat should just work. They are really focusing on what's unique and core to their business, which is kind of the matching algorithms and enriching their profiles. And so they've been leveraging other third-party software to go to market faster. So, um, they've been updating their chat experience using Sendbird. And what's interesting is that over the pandemic, people also still want to kind of meet and have dating, but it was very, very hard for people to meet physically. So what they kind of invented was a virtual dating experience that you might have read on TechCrunch sometime. They rolled out audio calling, audio dating, as well as video dating experience, all built on top of Sandbird. And what's interesting was that they had an idea and they wanted to go to full production with Sandbird and took them from the initiation to full production rollout in just 5 weeks. And that's from product and software engineering speak. That'll be about, what, 2 sprints? So it's a really fast, uh, full production rollout using a third-party API like ourselves. And then lastly, DoorDash has been our recent partner. Uh, if you're using DoorDash today, you might realize that a lot of your previous communication with the delivery person used to be on SMSs. Now they've brought it within the application using Sendbird, so you can actually communicate with the delivery person using Semper Chat, but also again, they use different part of APIs, whether it be Apple's authentication system or Stripe using payments. So they're using different sort of APIs to again, go to market faster with higher quality and reliability. So, you know, as our, as a product organization or as startups, yes, we have to ship, we want to ship faster, but we really don't want to reinvent the wheel. And again, that's where the whole ecosystem of APIs are here to help you go to market faster. And as an organization, you can learn faster as well. So just to sum things up, some key takeaways here. One is you can actually ship faster and more efficiently by leveraging third-party APIs, not just Semper, but just the really the entire API ecosystem. Second is the more you focus on your core user experience, which creates a differentiated experience and value for your customer. The rest of the API ecosystems there to help you achieve those goals. And lastly, again, as a software organization leader, you always want to have your precious engineering resources focusing and solving the right problems. And that's where you can again use the APIs to create even greater productivity for your engineering organizations and free up some of those resources to, again, tackle the most important problems. For your business. So, um, that's a quick overview of how API economy can help you go to market faster. Um, and yeah, I guess that's pretty much it. And I think we can, um, switch over to some Q&As. Um, I guess I can stop sharing. Okay, here's some questions. Do you see some API frameworks that are more robust or successful than others? This is a wonderful question. There are a couple of different ways to assess the API vendors, right? Obviously there's a technical evaluation that you want to do, whether you first want to spec out what are the set of core experience, whether it be user experiences or your backend feature requirements that you have. So you want to create the checklist. And the second is obviously like the security and compliances if you are part of that ecosystem. And third is kind of the commercials and legal. So, you probably want to have those kind of checklists of APIs evaluations so that you can actually assess the third-party vendors carefully. What's important also is that as a founder myself, we've also used third-party APIs where the companies would not actually last over a long period of time because all kind of companies are startups in their own nature. So you have to also make sure that the companies are financially stable, they are well-backed, and they're adopted by a lot of different customers. Out there, so that you know there's a bit of stability in terms of working with that or choosing that third-party API as the vendor of your choice. And also, there's also a way to look at different verticals and use cases a lot of these vendors work with. I'm actually stop sharing. So one thing to think about is, can you see yourself in the vendor's website? So if you go to a vendor's website, you can probably see customer logos or verticals or solutions or use cases. You need to solve. So if your API vendor is kind of focusing on those verticals and use cases, then they're probably the right fit for you because they're solving the problems that whether it be your competitors or similar players are already solving. So if the API players are solving the problems that you want to solve, but along with other players, you're getting all the benefit coming to you. So that, that's another way to kind of look at the API vendors or frameworks to partner with. Um, a few other questions, um, just to kick things off, for those in the audience who build some or buy some, I think a lot of people actually, the most number of people said build some or buy some. We're kind of interested in like what are the factors or frameworks you guys use to actually make those decisions? How do you make a decision when to build yourself, when or buy from a third-party vendor. I certainly love to kind of hear, get your feedback on those so that we can all collectively kind of learn. John, it looks like there's a question that was dropped into the chat from Jerry. Yeah. All right. How do you convince developers who are always wanting to build from scratch and their time is better spent going with some API products? Oh boy. That's a question that we deal with ourselves internally too. So one is, again, what we call this is a shiny object problem. All engineers love to build, but as a software engineer myself, I can kind of speak to this, hopefully. We love to build. What we don't like to do is actually maintaining and gradually updating for a long period of time, especially when that's not really core and kind of really, you know, a growth factor for your own business. Those tend to be like the infrastructures or something that's kind of a, again, commodity user experience. I mean, back in the days, we would never trust uploading user data to the cloud, or, you know, I love to set up FreeBSD servers and whatnot and install our own SMTP servers for emails and stuff like that. Nowadays, like, kind of who does that, right? And one way to kind of think about it is like, we have to ask ourselves how much of this building is really important, or how much of the software do you have to maintain and continue to improve over time? If you feel like maintaining, improving the software over a really long period of time is going to be really important for your business, then you have to have this heart-to-heart conversation with engineering leaders. Is this an area that we want to continue to dedicate, dedicate precious engineering resources for eternity to come? And a lot of times the answer is no. Like, again, if you look at the SMTP, the email servers, or cloud infrastructure, Nowadays, like, engineers don't really want to buy expensive hardware and install like Unix or systems like that just to get the servers up and running. You just want to, you know, have those things deployed on cloud. So I guess it's talking today what we call the concept of total cost of ownership. How much of a resource do you have to continue to deploy to do the so-called upkeep, maintaining and upgrading for a long period of time? I think those are really important points. And as engineers, those are things that we don't really like to deal with. So continue to focus on those total cost of ownership will be pretty important. And then again, the other thing is looking kind of ruthlessly, is this feature, is this shipping this feature or owning this IP going to be really critical to the destiny of our company, the success of the business? And to be honest, most of the time the answer is no. And sometimes there's a lot of throwaway codes where you kind of put a lot of engineering resources, build it, ship it, real only to realize It's not the user experience or feature that a lot of people adopt, then you want to rip it out or take it away. And if you work with API companies, it's fairly easy to kind of rip those things apart because you haven't really built the entire chest or tech stack yourself. But if you build the entire tech stack, usually they're very, very deeply integrated into your own product. It's first hard to rip things out. Two, there's a lot of emotional cost with engineering where people kind of are bummed out if the code they've written gets thrown away. So kind of using those as a communication framework to have those conversations with engineering leaders will be pretty important. All right, are we almost at time? So I think, I think that's it. Well, thank you for listening, and it was pretty exciting to share some thoughts with everyone. Thank you.