Ep#50: The Future of API Integration: Nango’s Innovative Approach ft. Robin Guldener (CEO, Nango)

Taylor Kenerson 0:12 Welcome to the Hyperengage podcast, we are so happy to have you along our journey. Here we uncover bits of knowledge from some of the greatest minds in tech. We unearth, the hows, whys, and whats, that drive the tech of today. Welcome to the movement. Adil Saleh 0:31 Hey, greetings, everybody. This is Adil from Hyperengage podcast, we have Robin from his he's the CEO and co founder of Nango. It's the largest platform that just a few months back, and is an open source platform for third party integrations for developer teams. So I would really appreciate it, Robin, first of all, thank you very much for taking the time today. And I would appreciate if you just go ahead and talk us through, well, how did you get to know this is really a big problem, because there are loads of other API platforms as well. Given your prior background, I'm sure that you pretty much live this problem for the longest times and how did you initially thought, what was the thought process of, you know, solving this problem for, for developers? Robin Guldener 1:14 Hey, Adil. Yeah, great to be on the podcast. And thanks a lot for having me. I think you know, me and my co founder, we both really experienced this problem at our last b2b SaaS companies. So we both built b2b SaaS products before, we had to integrate with other systems and external API's. And those integrations were super important for our customers. So it was one of the key features basic of the product was like, which software do we integrate? And how do those integrations work? How do we drive value? Well, we realized, though, is that on the software engineering side, those were really cumbersome to build. And we sort of like had to build out internal infrastructure to make building integrations less painful over time to make sure that we can actually support them as we scale. And so when we experienced that, or like, you know, there's got to be sort of a better way, like, This really sucks, what we're doing. We started talking to, you know, dozens of other, you know, software companies, b2b SaaS, companies, basically. And we realized that everybody's doing the same thing. So most of those teams today, they basically built those integrations, one by one, they built them with their like, you know, HTTP requests library, maybe some background job processing, but like, basically, a lot of internal frameworks get built. And that's what we're tackling. And we're starting with OAuth problem, basically. So OAuth is like the third way you integrate and authenticate to, like, third party API's. So it's the first step that you need to handle. And we built a much more scalable, you know, out of the box solution for this. Adil Saleh 2:38 Love it. Love it. So talking about some complicated, you know, integrations such as Salesforce, you know, do you have all the documentation and all the SDKs for your customers to make sure, okay, they are pretty much up and running. And they know everything that they you know, how they need to map all of those integration components. Robin Guldener 2:58 Yeah, so one of the most important things that we learned is that people have very different needs when they're looking to build integrations. And so one of the core tenants of what we're doing at Nango, is that we never restrict what kind of integration you can build with us. And we never restrict which parts of the API you can work with. And that led us to an approach where we're more of like, a developer infrastructure. So you can think of us more as like, you know, like a database tool, or like an application framework or a library than sort of like a wrapper around your API that will like sort of, you know, rebuild everything for you and restrict you. We're like rebuilding the hard technical stuff. Like the workflow, we do all the workflow management, we do all the access token management, we make sure they're securely encrypted in your database, we'll make sure that they're refreshed whenever they need to be refreshed, and all of those things, but then we don't tell you what you should go and do it as access tokens. So you can make any API requests that you want basically with us. Adil Saleh 3:55 Great, interesting. Okay, so let's rewind back a little bit. You know, you started a few months back, how did you find your co founder? What was the initial talks that you had? And then what was, you know, what was the vision that you shared? Robin Guldener 4:09 Sure, um, it was funny, you know, like me and my co founder, we actually met online on YC co founder match. We were both second time we was both second time founders this time around. And we basically match there because I think we were both like, sort of interested in similar spaces and problems. We had a few conversations over Zoom video calls. And he's looked so He's based in you know, Paris, France, and most of the time here in Zurich, Switzerland. We both travel regularly to San Francisco and the west coast. But yeah, learning like those, you know, initial calls basically kicked it off, we realized that we share like a same passion. And I think especially important for coworker for co founders is that like, we also share same mode of working, you know, similar values that are important to us. similar kinds of like vision that we had for the company and how we want to build the culture and the team and, and how I want to go about building the next thing. And then things just honestly started rolling from there, we started interviewing more potential prospects, learn more about the problem and started building. Adil Saleh 5:13 Because, you know, once you get bigger as a as a tech business, and you want to hire senior people from the industry, it is good for them to, you know, align on maybe principles and operating principle of sorts. But also, when you talk about your co founding team, he talked about your initial people that are going to be a players going in and out with you with success, good and bad, all of that, you need to be really short, make sure that you know, they are absolutely aligned on values, apart from everything else. So this becomes super important for a group of people, maybe a couple of people just like yourself, you both to make sure you are very much focused on one goal, as well as you have common values to share. So from that, from that point on, so how did you get started? You know, moving on to the YC. I know that they have an application process, that becomes complicated for a lot of startups. So how did that journey go along? Robin Guldener 6:14 Sure. I think one thing that we did early on, and I think that was it was part of the sort of the key talent. And you know, the values that we defined and shared right, is that we decided we want to test as much as possible about this problem space that we're solving, we're building as little as possible. So we wrote a blog post about this to actually how we like it did like the first three, four iterations on like the solution to this problem we basically did with very little coding. And so we would do is like, sort of, you know, we come up with an idea of like, okay, how can we actually help into engineers, build those integrations better was like, in one aspect of the problem, we can focus on first build, like sort of a landing page around it, or maybe even just craft like an email pitch, right, and like, try to convince basically a few people who give us some of their time and talk to us about their problems, or about like the potential solution, I think that quickly gave us feedback on whether there is interest around the way we were framing the problem and the solution and whether that message resonates, and that was always a reflection of a key value proposition, right, it'd be like, I don't know, we make process X faster for you, or we help you avoid y or, like, integrate once with us and get like those, like 15 integrations, you know, to systems like out of the box, right? And that quickly, like iterate. And so that's like how we basically, you know, traded our ways, sort of three, four, first iterations of the product, and eventually landed us on his off idea that we realized that really had traction, basically, people were starting to use it. Plus, we understood, like, you know, in hindsight, 20, out of 20, right, like, it's the first thing you need to do with an API. So it kind of makes sense that it's like the first thing to adopt for people. And then now that they're using it to have like, all those ideas, and other ways, though, how we can help them. And I think that's, you know, sort of a great, you know, motion that you get as an early stage product, once you get through that initial hurdle of how can I get somebody to actually use what I'm building, then typically, you'll find like a lot of follow on, or at least it's been for us, like you finally find a lot of follow on use cases and problems, and you can solve for people as well. Adil Saleh 8:16 And that's how you shape your product. Like based on you know, you navigate the gaps, you hand it to the people that are a potential, they use it to, you know, to the best of their use cases and processes, and then they come up with feedback that helps you get the product in the right direction. So where you guys are at now, you have like how much of the user experience that you've you've received in the beginning and regards it. Robin Guldener 8:41 So now we have, you know, a couple dozen companies use the product in production, basically, from like, you know, very early stage startups to like, decently sized businesses actually already, in adjusting it sort of in various different use cases. And we're, you know, continuously learning with those people. So for instance, we have a Slack community, which is the main way in which we interact with people actually, is that, you know, most people who install it, and they made it into a product, they join our Slack community sooner or later. And that's, you know, an easy way for us to get feedback, it's a great way for them to stay updated with new features that we're bringing out. And then because this thing is open source, we're also using GitHub a lot to collaborate with our people. So we have, for instance, GitHub issues on all the next things that we're planning to do. We have a public roadmap that shows everybody what we are working on. And we even have, like, you know, tax and issues that let them basically pitch in if they want to contribute and take on certain, you know, work on features that we have planned. And so continue together with the community and the users. Basically, we're shaping the product and iterating on it every week. Adil Saleh 9:44 Great, that's, that's very interesting that you are trying to get a close knit community of customers and advocates and they are sharing experiences. All of those are, you know, software engineers are entering tech teams, and they're trying to share their codebase from GitHub. GitHub, and based on their feedback, they contribute towards not only just making themselves use the product, and potentially but also helping you be a better product. So now talking about like, there's some big players have you know that like Postman, I'm sure they also have the one of these services like, like you like there is another product out of Texas Stoplight, they're also doing the similar, similar thing. So what is what is the plan on market positioning going forward? Robin Guldener 10:31 I think we really want to be like, you know, the easiest way for engineers to integrate their software with external API's. That's how we sort of like the struggle that we see and the struggle that we are passionate about, we see that most you know, b2b SaaS software these days, you know, it's kind of no longer in a one man Island, right? Like they're connected and live in a bigger ecosystem, they need to integrate with, you know, 5, 10, 15, different other tools that other customers are using, how those integrations are built, are actually like, used to be quite custom. So like, it really depends on the what you're doing in your product, how your customers are using those other products. And so there's little sort of overlap between different companies. But what we do see is that there's sort of like a common share infrastructure layer, that each of those engineering teams ends up rebuilding, the first one being OAuth, but they're stuffing around web hooks, reliable requests, handling, you know, sort of data synchronization, data mapping, and so on that we see. And then like, sort of our goal is basically to build layer after layer for this to help the engineering teams to make it easier to work with those external API's and to basically ship a lot more customer value faster. Adil Saleh 11:39 Cool, cool. So talking about customer experiences, you know, of course, you you give them the best experience you onboard them, then you make sure they adopted the platform. So how you guys are, you know, managing the post sales journey, like how you're making sure you're staying on top of your customer activities to make sure, okay, you they're served well, and, you know, if they're facing any kind of complication, you can just hit them up on Slack or something, or they, you know, you just expecting them to come every every time and share their problems, or maybe some of the feedback. How does that work? Robin Guldener 12:14 Sure. I mean, you know, so for us, we're a product lab sort of product, there's a free tier even on the cloud thing. But you know, so first of all, they have like different products, sort of like we it's one product, but it's different ways in which you can deploy it. So we have a cloud hosted version, where we manage everything for you, where we can also sort of see what you're doing, right, and we get like metrics and activities, and we can be proactive about reach out. But then there's the self hosted version, where you can take our product, and you can run your own server, and we don't actually see what's going on on that one. So you know, we cannot really be proactive and sort of tell you what's going on that one. And also, the monetization on that side is different, basically, like, as long as you're self hosted, we currently don't charge you anything. And there's no, you know, sort of plans to introduce monetization on that side. Soon, basically. And so what we also see is that, you know, we're not like, so we're not selling people up front, even on the cloud, right? It's like a free tier, us, you just sign up, you start using it. And so we see people adopting it that way, and then basically grow their usage over time, which then, you know, sort of means that they ended up being like stuff, and monetization aspect to it. Adil Saleh 13:23 I spoke to have spoke to this with Jitsu team as well. So they are open source, too. And I was, you know, we were also, you know, one of our friends is building a very big product, and doing the integration on top of all their their open source models and everything. So how do you guys manage the unit economics on this? Like, let's say, one of your customers, you know, they have like, of course, it is just an API integration. So how does the data and and the scalability of your customer would affect the unit economics? On the server side, as well as on the database side? For you? Yeah, Robin Guldener 14:02 I mean, I think in general, we're thinking about this as sort of like a usage based thing, right? Like sort of, we want to be aligned with the value that we're generating for our customers. And broadly speaking, the more we power of your integrations, and the more integrations we power for you for the more of your users, the more value we are delivering. And we're sort of looking to capture that too, to be honest in like, you know, as we mentioned, like the product is just a few months old, I think, you know, monetization is not the core tenant for us right now. And it's not the thing that we're, you know, most of the time and about, we sort of have ideas on how to pricing, you know, might be worth in the future. But I think this is, you know, very much still an ongoing process of discovery together with our customers to understand basically what is a fair pricing model? And how can we make sure things are good for both sides? Adil Saleh 14:46 Knowing of course, once you're going to be, you know, doing all the GTM frameworks, the pricing packaging, that will definitely come into play, and you're just trying to analyze the patterns and, of course, the back office, you're trying to make sure that you're on how you can do the unit economics in a more scalable version, once you get like more customers more and more users. Okay, so now tell us more about how do you get into a Y Combinator? How did how did it turn out for you? Like, was it good or bad? What are the pros and cons, and I'm sure so many YC startups that have also come up and share their opinions. And, you know, it's just their experiences. And then rest people that are listening, you know, already said founders, they're trying to get into this winter batch coming up, and they'll have some two cents from you. Robin Guldener 15:40 Sure, I think, you know, we decided to do YC, we apply to YC, back in September last year, on September 28. Two, we got accepted very early into the program, I think YC has been really good for us, it definitely made us faster, on many points, part heading, because of the kind of product that we're selling, you know, there's a lot of an initial and fast feedback we could get from Moto batchmates. And that was definitely helpful. But also, I think, the YC partners, you know, advice busy, they've just seen a tremendous amount of companies successful and less successful over the past 10 years, and have been a really, I think, developed good frameworks. And you say, like, sort of benchmarks for what, you know, good looks like and like sort of a lot of pitfalls, and common mistakes that they see founders make. And so that has been great. The YC alumni community is also very supportive. And there is a, you know, fast growing sort of open source community within inside of the YC. community, that definitely has been also very helpful for us in terms of getting feedback, in terms of getting advice on sort of, like open source specific questions, and just helping us basically move faster. Adil Saleh 16:56 Great. So I mean, I'm, I'm also familiar with, like, how close your community is, how supportive the community is, and a lot of these startups to get their initial customers from from their beds, batchmates, and the, you know, the former YC products that did, so how did that turn out for you, like, of course, you want it, Robin Guldener 17:16 we have some users from that side, though, they're not the majority of the users of the product right now. So we do have, you know, some batchmates, you know, use us we do have some YC alumni who are using us very successfully. But we also have people from outside the YC community, who are using us very successfully. And it's also you know, the group a big chunk, where we're seeing the growth coming from. So I think it's definitely helpful. If you're doing something regarding like, sort of as a b2b kind of company, b2b SaaS, or something similar, I think you'll find a lot of value in talking to your batch mates and getting feedback fast, because people are, you know, in a similar situation as you, right, like everybody's trying to understand better how their idea works. And there's actually value in what they're delivering. And so people tend to be brutally honest with you. Which is great, because like, there's nothing worse at this stage than sort of like, you know, kind of nice feedback, but it's not really like telling you that there is actually a problem. And it's kind of like, you know, you're missing that. Right. So I think, from this perspective, it's a really good community. Adil Saleh 18:20 Okay, great. Thank you very much for explaining that. Okay. So a lot of these even YC people like Microsoft, oh, and Dalton, all these folks, they preach too much that, you know, before writing a line of code, you just gotta go talk to your future customers get initial feedback, and make sure I'm not sure it's if that is, you know, that is practical in your case, because you are more of a developer tool. However, how does that what is in European that has worked out for you? Like, have you built the product and taken and headed over to the people build a minimum viable product of it? And then got the feedback to get some integrations? Yeah, Robin Guldener 19:02 I think it's a really tricky, and a really interesting question, honestly, this one. So I think like, as I mentioned, you know, we did a lot of initial idea and problem validation, before without sort of building any product. And I do think it has made us faster, in many ways. At the same time, I think there is something there is a point sort of, that nobody can really put a finger on, where you sort of have to jump and said, Okay, I do think there is something there. And we're going to start to build something and start to like, sort of put it out there and have people like, you know, see if we can get people to actually use it, especially if you're trying to do something like we're doing or you know, we're doing a lot of like, community led bottoms up kind of adoption, you know, directly working with the engineers who are using the product. And this is really hard to sort of validate if nobody can actually use it, right. Like there's no way to validate whether people would go like you know, download your Docker container and try to run it locally, and then like open GitHub issue. doesn't start contributing ideas on how to improve it. Unless you're sort of out there. And it's actually usable. I did not, you know, today's day, I don't know, really, you know, how you how I would like pin that down and said, Okay, now is the right moment in time, when you should go from like sort of desk research, to actually getting your hands dirty coding and starting to ship do I think one important part is that even as we did, start coding started shipping, we never stopped sort of the desk research and reaching out to people and just talking about the problem, which worked, I think, helped us attract the first users for the actual product later on, but also informed us and like, let us like, learn a lot of things that you might have discovered through the product usage as well, but you know, would have taken us weeks or months longer to get there. Adil Saleh 20:48 Cool. I love that, you know, you know, it is equally important for you to of course, talk to the customer letter, but also give them something visual. A lot of folks, they they tell you, Okay, work where I can see it, like, do you show me anything moving, a lot of people will come up and say, Okay, it's good to have verbal feedback and getting to incorporate everything that you have inside your head and getting it transformed. But it is even more important, more useful to have them something visual, and and keep building the product, maybe prototype, maybe any figma you know, design or any movable interactive design of source. Great. So now one last question before I set you free. And I really appreciate that you are being so expressive. Now, thinking of today, you have good users, like not paying users but active users that is even more powerful. For just to be clear, you also have paying users Yeah, oh, great. He you said that it's an open source. I thought it's more of a free like jitsu. It's a free platform. So you have paying user, so are you looking forward to just self, you know, going self funded bootstrapping, or you want to raise some money. Robin Guldener 22:00 I think that's a path that, you know, we're continuously working out as we go. I don't think we have like a set opinion on this sort of today, we definitely do have a big vision about this, you know, becoming the standard that developers use to build native integrations and SaaS products for this employee, it will make sense for us to go in and raise additional funding when the time is right. But honestly, we're really just focused on the users the value that we provide right now and how we can improve that, and basically grow faster. Because you know, if we want to become the standard, then there's still like millions of developers out there who need to hear about us who need to adopt us and for whom we need to be able to solve a really complex problem. Adil Saleh 22:39 Cool, cool. And if there is one thing that you think Nango right now is missing for developers. Robin Guldener 22:48 We just got another request today that, you know, I think we've heard a few times is like we do the oldest, like, you know, OAuth flow API authentication things for you. There's another common mode of authentication that we want to support is called API keys. And so that's definitely something that we would like to add in the near future Adil Saleh 23:04 help me understand that the API key that I was integrating Calendly. Well, with Zapier, just a few days ago, it was Robin Guldener 23:06 like how Zapier can make calls to your calendar API, for instance. So there's two like big ways in which API's do authentication. The first one is OAuth. And the second one is API keys. We currently support OAuth. And it's really where I think like, you know, more has less usually for developers. But then you also have some API's where you need to use API keys and other people have, you know, their OAuth tokens and their authentication stored in mango and handled for them. They're kind of like, Oh, why couldn't you like, you know, store my API keys to that would be really convenient. Yeah, so that's definitely something that I would like to improve in the future. Adil Saleh 23:48 That'd be great. And how, like, we talked about this. What about Salesforce? Like, you know, like, is there any kind of complication, this is just for my understanding, I'm so sorry. I'm so non techie. So non technical. So like, when it comes to infrastructure, as big as Salesforce, you're trying to make sure you integrate all of the Salesforce natively all the data that's inside for all the sales teams, as well as all the tags, all of those, you can say, objects, custom objects that they have inside. So how do you enable your customers like there will be lot of in the mid market, in the SMB spaces that are using Salesforce that might consider, you know, Nango for the integration part. And it is super complicated, because we're doing it. So how do you think that Nango can make it even more seamless, and sort of a plug and play when it comes to Salesforce? Robin Guldener 24:47 Sure. So like, you know, there's two parts to this right. First thing is like you need to be able to connect to the Salesforce API and connect and access the customers data inside of the Salesforce API. And that's really where we're helping you the most today. Okay. So, you know, unfortunately, Salesforce has a very complex and not always quite standard workflow. They do a lot of weird things around like sort of refresh token handling, using the different base URLs, like sort of different technical terms, right? Like they don't very feel like they don't ring a bell. But like, those are issues that kind of your developers have to solve to even just get access to the Salesforce API and to start to be able to pull data from your customers basically. And so those are the things that we help you with today. So instead of like dealing with all of those things like a Salesforce integration with us, it's just like two lines of code, basically, for your developers. And then they can go and use all of the Salesforce API's. And so the next question is sort of like, okay, what data do I need for my customers out of their Salesforce accounts? You know, Salesforce, as you mentioned, is a huge platform, they offer different products with a lot of different, you know, sort of features. And then it usually comes more down to like sort of a product question of like, how does our product interact with Salesforce as products were, which of their products we want to integrate? How does that integration work on a sort of like workflow or user level? And then like, the next step is once you understand that, for engineers to take that and translate it into, okay, what does that mean in terms of like, what kind of API's and endpoints we're using? How are we making those calls, and that's where we would like to help you a lot more in the future. But today, honestly, it's hard to even just get access to the Salesforce API and just start making API calls, we typically see teams take like several days to figure out all the stuff there and like iron out all issues, and you know, with Nango can just be much faster. Adil Saleh 26:35 Great. And same goes for like Segment is a little easier. Because inside Segment, we have segmented version to amplitude segment. Inside segment, there are some parent events. And then there are some custom events. So they go like a user level on cup level, you just need to map those. So I'm sure this is quite easy with with segment using Nango. Robin Guldener 26:57 Right? So I think I found is that correct ending segment is solving a different problem for you. So a segment is your event data that you capture in your product to use different SaaS tools, right? integrations that we are talking about are the end product integrations that live inside of your product, where you don't move your own data, you move your customers data, basically. So your customer would go into your product would connect their Salesforce, and then you would pull in the leads or contacts or opportunities, which I think is slightly different from what most people use segment for, which is they use it anymore for like the analytics tracking or like, person has like a certain button inside my product. And now I want to send this data to amplitude and Mixpanel and my data warehouse and you know, five other things. And so I think it's like a different way, I think, yeah, it's a different way of building integrations basically. Adil Saleh 27:48 Got it. Got it. So segment is more of a pipeline like it just pumps the data. Like it's just, it's a gateway for all the data. Robin Guldener 27:56 Yeah. So I think broadly speaking, in integrations, there's two kinds of integrations, there are integrations to where you as a company, connect all of your different SaaS tools together. So this is where Zapier plays where Segment plays, where trade io plays Ricardo, and so on. They help you basically, as an individual company, connect all your different systems together. And then there's the other kind of integrations that we focus on, which is the integrations that are built into a software product, where that software goes and connects to your different API's to pull in the customer's data. So this is like, you know, MailChimp, integrating with Shopify and Salesforce and HubSpot to pull in data from their customers accounts there so that they can send email newsletters to all those people from all their systems. And so those are typically called like native integrations, because they're natively built into the product that you're using. And we're really focusing on helping engineers build those native integrations in b2b SaaS products. Adil Saleh 28:57 Love it, love it. And those are going to be it can be third party integrations, like external API's using external API's. Robin Guldener 29:05 Right? It's usually so it's external API's from the point of view of the software that is building them, right? Because let's say you are MailChimp, right? And like you, your system is MailChimp. And now you want to pull in data on people who have ordered stuff on Shopify stores. So you would connect to the Shopify API on behalf of your customer to pull in your customers data from Shopify does the work with the Shopify API and the same way Salesforce, HubSpot, and so on. Adil Saleh 29:33 Thank you very much. And using Nango Yeah, Robin Guldener 29:35 of course, authenticating all of that with Nango. Thats the goal. Adil Saleh 29:39 Love it. Love it. Love it. Thank you very much, Robin, for giving me this education. I've learned a lot. And who knows you have added a lot of things to my knowledge regarding this API integration industry. Previously, I was so familiar with only familiar with Postman. Maybe API Matic stoplight, some platforms in the mid market. And now I know while you explain it that how unique of a use case that you are serving. So I really appreciate you took the time today, Robin and thank you very much for being such an educator. Robin Guldener 30:15 Thank you for having me. Adil Saleh 30:18 Have a good rest of your day. Robin Guldener 30:20 Thank you you as well. Adil Saleh 30:21 Thank you so very much for staying with us on the episode please share your feedback at adil@hyperengage.io We definitely need it. We will see you next time in another guest on the stage with some concrete tips on how to operate better as a Customer Success leader and how you can empower engagements with some building some meaningful relationships. We qualify people for the episode just to make sure we bring the value to the listeners. Do reach us out if you want to refer CS leader. Until next time, goodbye and have a good rest of your day.