How APIs are Changing Modern Development with Sendbird

All right. Hello everyone. Hope everyone's settling in. It's good to meet you all. I'm John, founder and CEO of Senber. 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 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 engine 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 us third party vendors. And then lastly there's still a lot of organization today who want to build as much as possible internally and they really own that IP and then have a tighter control on your software environment. So love to get a quick sense. Seems like the results are already coming in quite interesting. So 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 dive right in. So I've been a software engineer by trade and I've been building product and engineer 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 walking the park is 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 resume was 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 where as a software engineer I want to build everything myself. I want to have a tight control over my own software and I 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 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 abundance of API technologies that we can leverage to go to market faster, which also offers greater flexibility and higher quality given that it has a lot of proven points working with other customers as well. So 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 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. 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 identifying, 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 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 experience that are unique to your own business by leveraging proven technologies so that you can go to market much, much faster. And kind of taking a step back, what does it mean if you look at any kind of 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 very small, with everyone kind of doing everything on the remove. Then the ecosystem kind of evolves where there are multiple different organizations that are kind of all contributing to different parts of value chain. And then ultimately, as the industry becomes large enough, companies really tend to focus on what's unique 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 Horroy's comparison on the API economy. If you look at the automotive industry back in the 1920s when Ford Motors and other companies started to come out, they really own 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 a place in the ecosystem where they are now contributing to this massive, massive industry. And we're seeing something very, very similar happening in the software industry as well. So what's really happening as this kind of industry evolve 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 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 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, 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, 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 and sophisticated over the 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 take risks in by creating your own unique differentiated value for your own software? And then which are the parts you feel is common enough where you can kind of start borrowing from different parts of the ecosystem to de risk your business and 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. There are a couple of lists that we like to look at. One is, is this technology hard or messy to get it right? There are of course things that are really unique and core to your business where you don't want to 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 difficulty. That's where you just start look elsewhere and look at the other API vendors. Second is when 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 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 like disappointed. Or 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 doesn't really create a differentiating factor for your business. That's kind of when you know you have to start 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 hard or messy 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 disinggrities. It should just plug, plug, plugin and just should work very, very smoothly. And the fifth is that 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 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 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 vs what are the things that you want to kind of own and build it yourself. So just to give a couple of examples, keep trucking. A very massively successful company have been using our are and or having leveraging APIs to manage the advanced fleet management. So the focus is keeping the truck drivers safe, compliant and efficient on road. And as you can see they've been leveraging different kind of APIs to really build up their product. And they've also used Sanbert 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 online reviews. And again they've been leveraging different kind of APIs whether it be locations or calendar sync, using Chronofi to book appointments, but also have been using Semburg to power their communication piece for planning purposes. And also Hinge has been one of our long term customer part of the Match group have been using Sember 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 they've been updating their chat experience using Semburg. And what's interesting is that over the pandemic, people also still want to kind of meet him 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. You might have read on TechCrunch sometime they rolled out 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 five weeks. And that's from product and software engineering speed. That'll be about what, two sprints. So it's a really fast full production rollout using a third party API like ourselves. And then lastly, DoorDash has been our recent partner. 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 Semper. So you can actually communicate with the delivery person using Semburg 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 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 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 that's a quick overview of how API economy can help you go to market faster. And yeah, I guess that's pretty much it. And I think we can switch over to some Q&As. 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. 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 company is not, 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 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. Let me actually stop sharing. So I want you to think about is can you see yourself in the, 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 that 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's another way to kind of look at the API vendors or frameworks to partner with few other questions 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 or, or buy from a third party vendor? I certainly love to kind of 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. 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 growth factor for your own business. Those tend to be like the infrastructures or something that's kind of again, commodity user experience. I mean back in the days you never trust uploading user data to the cloud or I love to set up free BSC servers and whatnot and install our own SMTP servers for emails and stuff like that. Nowadays 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 precious engineer 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 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 have those things deployed on cloud. So I guess it's talking to them. 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 engine resources, build it, ship it, only to realize it's not the user experience or feature that a lot of people adopt and 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 that's it. Well, thank you for listening and it was pretty exciting to share this thoughts with everyone. Thank you.