Enjoying the podcast? Don’t miss out on future episodes! Please hit that subscribe button on Apple, Spotify, or your favorite podcast platform to stay updated with our latest content. Thank you for your support!
Most fintech companies, and increasingly banks, rely on API integrations to run their business. Yet, building and maintaining these integrations can be time consuming and complex, particularly when it is only a part of what an engineering team does. Today, you can outsource these integrations to companies that specialize in this type of connectivity with a unified API platform.
My next guest on the Fintech One-on-One podcast is Shensi Ding, the CEO and Co-Founder of Merge. She saw the challenges of API integrations in a previous role and decided this was a problem worth solving. She has built Merge to specialize in helping companies with their API integrations, leveraging one API to add hundreds of integrations.
In this podcast you will learn:
- The problem she saw that led to the founding of Merge.
- What a unified API is and how Merge offers this.
- The core categories where they are focused.
- Why AI is such an important category for Merge.
- Why large banks and fintechs trust Merge to manage their API integrations.
- The number of integrations they are working with today.
- What is involved in adding a new integration.
- How they make sure these integrations don’t break.
- How they work with custom integration requests.
- What is needed to get these integrations up and running.
- How Merge is helping Ramp for their HR integrations.
- Their experience working with banks.
- Why they like working with companies that are having challenges with integrations.
- How they work with the non-technical customer success teams.
- Why the human element is so critical for Merge’s success.
- The process in adding a new integration into the system.
- How they are using AI internally.
- How they work with companies that don’t have a robust API yet.
Read a transcription of our conversation below.
FINTECH ONE-ON-ONE PODCAST NO. 531 – SHENSI DING
Shensi Ding: There aren’t that many people who have built integrations before. And whenever you end up hiring anyone, there ends up becoming a lot of institutional knowledge that has to be documented, it has to be maintained. And the long-term maintenance of those integrations ends up becoming very expensive for these companies. And they have, of course, something else that’s really core to their product. It’s not integrations. Integrations are a means to an end. And so because for us, this is the only thing we can do and we can really assist them and also accelerate what their customer success looks like and then long-term help them maintain these integrations, it doesn’t really make sense for them to own them. I firmly believe that no company can be uniquely good at integrations, they can only be worse. The only way for you to be uniquely good at integrations is if it’s the only thing that you focus on, and that’s us. My entire company, every single person here, is an expert at APIs, unlike any other business. It just doesn’t make sense for a large financial services company to gain expertise in this.
Peter Renton: This is the Fintech One-on-One podcast, the show for fintech enthusiasts looking to better understand the leaders shaping fintech and banking today. My name is Peter Renton and since 2013, I’ve been conducting in-depth interviews with fintech founders and banking executives. On the show today, we are talking API integrations with Shensi Ding, the CEO and Co-Founder of Merge. Pretty much every fintech company, and increasingly many banks, need to do API integrations with tech companies. Now you can do this in-house with your own developers, or you can hire Merge, who specializes in API integrations with over 200 different connections in production today. We talk about how this works, what is involved in getting started with Merge, why fintechs and banks choose Merge instead of doing these integrations themselves, how they’re using AI, and much more. Now let’s get on with the show.
PR: Welcome to the podcast, Shensi.
SD: Thank you so much for having me. I really appreciate it.
PR: My pleasure. So let’s kick it off by giving the listeners a little bit of background about yourself. You’ve been doing Merge for a few years now, but I’d like to get sort of the full picture here of what you’ve done in your career to date.
SD: In the very beginning? How far back?
PR: After college, yeah, after graduation.
SD: That sounds good. So I did study CS in undergrad, but I ended up deciding to go into investment banking after school. I think that was a really great experience for me to understand what working at a large financial services company was like. I actually worked at Credit Suisse, RIP. It was a fantastic experience though. I made a lot of great friends, did a lot of great deals, and it taught me a lot about the fundamentals of business. But because my background was in software engineering, I was really interested in moving to California and diving into tech. So I went to Silver Lake, joined their growth equity team, got the best exposure to founders and startups, and just learned a lot about how VCs evaluate companies. But it wasn’t quite in the weeds enough, and I didn’t feel like I knew what it was like to actually work at a company. So I started interviewing for different startups, and I had the opportunity to become Chief of Staff to the CEO at a cybersecurity company back then called KDM, and then later renamed to Xpanse. I worked directly with the CEO for around two and a half years up until right around the acquisition to Palo Alto Networks.
PR: Okay. So then, what was it that you saw that led to the founding of Merge? Tell us a story there.
PR: So I mostly saw this problem from a P & L perspective. When I was Chief of Staff, Tim, the CEO at Xpanse, gave me so much exposure. I was allowed to go to every single executive sync. I had full email access, like email inbox access. He really gave me a lot of exposure. And in a lot of the executive syncs and board meetings, one thing that kept coming up was integrations. We were noticing that a lot of our competitors were investing in integrations and we didn’t have any at the time. So we started investing in like a CSV export functionality or CSV import functionality. We launched an API. We then tried to hire contractors to build the integrations for us, but none of these methods really solved the problem. And we continued to really suffer on the sales side because of the number of integrations we had. So we just dug deep, ended up hiring a team of engineers, and it was very expensive for us on the R &D side. But not building these integrations is also very expensive for us because we were just losing deal after deal. And so you end up just losing a lot on the P &L side if you don’t invest in integrations. And that got me thinking, why hasn’t anyone solved this problem yet?
PR: Right, right. That is interesting. And we were chatting before we hit record here. I think it’s interesting that it hasn’t really been solved. I mean, there are some companies that do a few integrations here and there, but maybe you could take us through, I mean, you’ve kind of described the product, the core of what you do, but just give us a little bit more detail there. What is it that Merge does exactly?
SD: We help companies add integrations to their product with a single API. So what we offer is what we call a unified API. So you integrate once into a common data model that allows you to read and write data in the same exact format, and we handle the translations. So, for example, a lot of large financial services want to integrate into accounting and HR platforms. I’ll just start off with accounting. So, say you want to integrate with NetSuite and QuickBooks and Xero, but the way to integrate with all these different systems varies. There are different endpoints you have to call, the data comes back in different formats, and you have to end up doing a lot of normalization. You also have to handle the authentication, the rate-limiting, the pagination, all that varies quite wildly between every single platform. But your customers are asking for these integrations because if you don’t offer them, they just can’t use your product. And so you end up having to hire a lot of engineers. There really is no answer for this other than just humans.
PR: Right. So then this is a problem across tech. It’s not just a financial services problem, but what are the verticals you’re focused on, and what attracts you to financial services?
SD: There are three core categories that we focus on heavily. The first one is HR, HR tech, and payroll. So that means like helping any productivity tools related to HR, like performance management and intranet. We also help a lot of payroll companies with their accounting integrations as well. The second category is financial services. So usually expense management goes into those AR, AP use cases. So we help a lot of large financial services with specifically like posting invoices, monitoring invoices, we’re seeing all the different transactions. And that’s been very exciting over the past few years. And then the third category is AI. So there are a lot of AI use cases that have been popping up, especially over the past few years, where previously, companies would integrate with just one or two categories, but now, all data is relevant for the customer. So, increasingly, a lot of AI companies want to pull in every single platform of their customers’ data so they can provide better insights.
PR: That’s interesting. So maybe before we dive into financial services, let’s just take a second to talk about AI integration. So, are you talking about the major LLMs, the AI platforms? Who is using Merge?
SD: Yes, them and then as well as many other companies. My thesis is that every single traditional SaaS company is going to have to add AI into their product. It’s going to just be the default expectation of the user. And usually the easiest way to add AI into your product is to add some form of AI search. So that means making it really easy for people to find information, making it really easy for people to combine information from different systems. But that means you need to have a lot of integrations. AI is inherently extremely data-hungry, and for you to provide the best customer experience, you just need more integrations and more data.
PR: Okay, so without getting too much in the weeds, say someone wants to put, you know, a ChatGPT-type interface into their product. And does that mean that you don’t just interface with ChatGPT, you interface with other data libraries, or how does it work?
SD: There are a few different steps there that have to happen before. So one of our customers is a company called Guru, the founder is Rick Nucci. He actually started a company called Boomi, which was like the OG integrations platform back in the day. So he ended up starting Guru, and in around 2022 or 2023, once AI really started blowing up, they added an AI search functionality into their product, and we ended up helping a lot with some of the integrations. So, there is a ChatGPT-like interface where you can type questions and queries. But in order for the data to be able to then surface in that search, you need to connect your integration. So there’s a pop-up model that’s showing with like, here’s all the different integrations you connect, select which vendors you are using. So one company might choose like, I’m integrating with Salesforce. I also want to integrate with Asana. I also want to integrate with Mytrana. Once you have authenticated, then that data starts syncing. And then that ChatGPT-like interface that you’ll see in the product will then be able to return any insights from it.
PR: Gotcha. Okay. Okay. So let’s, let’s talk about financial services. And one thing that, when I was sort of researching you and your company, I was thinking about the fact that for some fintech companies, their integrations are so key. They’re foundational to their product. Like they wouldn’t have a product if they didn’t have these integrations. So, for something that is so foundational, why should a fintech company, or even a bank, for that matter, why should they trust Merge to do those integrations?
SD: I totally agree with you. It is very, very scary to have the responsibility of this on Merge. But we are very proud to be powering for some of the largest financial services companies in the world. And the reason why these companies trust us is because this is the only thing we do. We are experts at integrations. And the world of integrations engineers is still pretty small. There aren’t that many people who have built integrations before. And whenever you end up hiring anyone, there ends up becoming a lot of institutional knowledge that has to be documented, it has to be maintained. And the long-term maintenance of those integrations ends up becoming very expensive for these companies. And they have, of course, something else that’s really core to their product. It’s not integrations. Integrations are a means to an end. And so because for us, this is the only thing we can do, and we can really assist them and also accelerate what their customer success looks like and then long-term help them maintain these integrations, it doesn’t really make sense for them to own them. I firmly believe that no company can be uniquely good at integrations. They can only be worse. The only way for you to be uniquely good at integrations is if it’s the only thing that you focus on, and that’s us. My entire company, every single person here, is an expert at APIs, unlike any other business. It just doesn’t make sense for a large financial services company to gain expertise in this.
PR: I can see where you’re coming from there. How many integrations are we talking about here? Like, I mean, what do you have?
SD: We’ve run 220 integrations. It’s definitely a lot of work.
PR: Yes. So, what does it take to add a new one? Like, every category has a few main players, and there’s a long tail sometimes of 20, 30, 50 players. Obviously, you want to integrate with the main players because that’s what most people want. But what does it take to add a new one for that long tail?
SD: So building the integration and adding it isn’t the hard part. It’s the long-term maintenance, the quality that you end up having to dive deep into, especially as you start moving more enterprise. So, when it comes to a simple REST API, it can take us around two to four weeks, and that includes some conservative buffer for testing. If I’m building integration on the weekends and I do not care a lot about quality, it can just take like one or two days. But that’s not what our customer base looks like. We have some of the best companies in the world relying on us, and so we end up adding a larger buffer for QA. If it’s a SOAP integration, of course, that’s harder, and we always add extra buffer just in case it becomes more complicated than we expect. And so that ends up taking four to six weeks. With SOAP integrations, oftentimes response bodies can vary a lot more wildly and it’s easier for the integration to break. And so we also keep those integrations in beta for longer just because it’s much more likely for there to be an edge case or for a new field to return, or for something to actually be an array instead of an object. And so we really account for that in our testing. If it’s an on-prem integration or like a very, very custom platform, that needs to be custom. We’ll need to talk to you and your team about which platform. We ended up building a QuickBooks desktop, which is an on-prem integration, and we did work on a pretty fast timeline for that. But that’s not always going to be realistic with some of these larger, more old school platforms.
PR: Right, right. So let’s talk about the maintenance of these platforms because every tech company is releasing new versions of their API, and you’ve got new features for their software. I mean, as you said, the easy part is doing the first integration. What’s involved in maintaining these integrations to make sure nothing breaks?
SD: Oh my gosh, so much. It’s constant alerting, on-call, having people available, and really great processes. Our team, we have amazing processes when it comes to maintaining these integrations. So if something breaks, we immediately get alerted. We’re able to oftentimes catch these breakages before our customers are. Of course, there is such a wide surface area for these integrations breaking. Sometimes, something does pop up. But the benefit of using Merge is that we have probably the largest number of end users in the world to battle-test our integrations at all times. And so by the time you onboard onto an integration for the first time with Merge, it’s like you’re using a much more mature integration because you already know other companies have used it. Versus if you build an integration in-house, it’s always going to run into those edge cases, especially in the beginning. So yeah, we just have a lot of focus on it, and we also have a lot of testing and tooling in place internally.
PR: Right. Do your clients also say, well, the way we integrate with this particular company, we want to add new features. I imagine that means you have to change the way you integrate. I mean, if someone wants to do something new.
SD: Not necessarily. So what we end up doing is we try to make sure we’re productizing things as much as possible. It was one of the things that we really, me and my co-founder, we really held firm to in the very, very beginning. We knew if anyone wanted anything custom, we had to productize it. It couldn’t be that we were adding something just for one customer. And so what we ended up doing was building this functionality called supplemental data. So, the goal was anything that’s possible by building directly was going to be possible through Merge. And so we created a library of products including passers. You make direct pass request, we handle the authentication for you. You can also add custom fields, both via API in our dashboard and then also in our embeddable front-end components so your end users can do it on your behalf. We also added API functionality to pull all the custom fields available in an API so you wouldn’t have to manually add every single one. And the list goes on. We really invested a lot in this customizability. We also allow people to override any of the data if they disagree with our mappings or if someone has stored data in an incorrect field. So there are multiple ways to get that data if you want to be a little bit more custom because inevitably, there is going to be a situation where there is a really big deal. They want a certain field that is only available on one platform, and it just doesn’t make sense for Merge to add it to our API. So none of our customers are ever blocked by that.
PR: Right. Gotcha. Gotcha. Okay. Let’s, let’s take an example. Let’s say I’m a fintech company. I’m listening to this podcast, and I really, you know, I want to add some HR connectivity to my app. I want to integrate with say ADP, Workday, TriNet, Gusto. Take us through what is involved there, particularly like timelines, resources from the fintech company that’s hiring you. What’s involved to get all those integrations up and running?
SD: It only takes one PM and one engineer. So you just have to allocate two sprints, which is usually around like two to four weeks. I’ve definitely seen people integrate into Merge in two days, but I’ve also seen larger companies take much longer. So it really depends on intent. But really, all you really need is around two to four weeks and two people.
PR: Right, right, okay. Okay, so on your website, you mention Ramp, Revolut, Bill, Navan, all using Merge. I mean, those are some really big fintech names. Maybe you can take one or two of those and just tell us how they’re actually using you.
SD: Well, we were very lucky that this was actually one of the first use cases that started blowing up when we first started. So, all these different companies, what they started noticing was that they had a leaky bucket issue whenever they onboarded a customer. What would happen is they would sign a great logo, they were super excited, but not every single employee would end up using the credit cards. And for many of these companies, they end up making money through the transactions. And so it’s really critical to ensure that the entire organization is onboarded onto the platform and that everyone uses the credit cards. It’s also a security issue if someone has been terminated and they still have access to their credit cards as well. And so, Ramp is actually the first company to look to us and ask if we could help with their HR integrations. And so, what that is helping is for the entire expense management industry, we usually power offboarding and onboarding. So that means you can pull all employees that have just joined a company. You can see their manager’s information. You can add any rules based on that. You can also see location information if you want to mail a physical credit card. And then, of course, when someone is off-boarding or leaving the company, you can also terminate access automatically as well.
PR: Interesting, interesting. And what about banks? I mean, banks don’t typically have the pace of technology adoption that the fintechs have and the pace of, sort of, I guess, integration needs. Like you’ve mentioned, you’re working with some large financial services firms. Does that include banks?
SD: Absolutely. So many of these banks are actually very in the know when it comes to the news, looking at certain tech companies and seeing what’s out there. So a lot of these companies are, a lot of these banks are actually like the very most enterprise products of comparable like Silicon Valley startups. So, for instance, a lot of large banks have expense management products that are comparable to Brex and Ramp. A lot of them also have cap table management companies, similar to Carta. Others also have like new, net new transaction products that are pretty unique in the industry that only they could offer. And so for all these different companies, we help power their HR and accounting integrations.
PR: Okay, okay, that’s interesting. Then, do you typically see situations where a company has tried to do this themselves, and it’s gotten out of control as far as cost or time, or what have you, and they bring you in, or what are the sort of reasons that companies come to hire you?
SD: All the time. It’s actually a better situation when someone has built an integration before, and they understand how painful it is. And actually, probably one of the largest logos that we’re currently talking to, they had an engineer try to build their first integration, and it was such a traumatic experience for them that they were just like, we don’t want to do this anymore. Like we need to find someone else. And so that’s how we got involved. So it’s oftentimes actually a better experience. The team is a little bit more knowledgeable about what’s possible. They’re a little bit more understanding, and they have higher-quality questions. But that isn’t always the case. Sometimes, there is an existing competitor, an older platform that’s involved. They might have used some kind of workflow products originally, and they’re trying to migrate off because Merge is a more efficient system. Or they just have a lot of engineers, and they’re trying to figure out, okay, how do we end up making this more efficient? So we really see it all across the board, but some knowledge of integrations helps us a lot. But we do oftentimes see companies who are just like, we’re launching, we know we need integrations, and they don’t have a ton of knowledge about what’s going on there. And our sales team is very, very good at educating them so that they can feel empowered in their decision and they understand what’s going on after they sign as well.
PR: Okay. Okay. So then, when you’re working with these companies for the first time, you can use Ramp, for example. You get everything set up, and then how does your relationship evolve over time? Obviously, it’s going to be different, I imagine for different companies, but do they see that, oh this is really, really easy? Let’s do more. How do your relationships with your fintech and banking partners evolve over time?
SD: It’s interesting because oftentimes the evaluation is first with a product manager and then obviously the engineering team that is testing out the platform. But then when it comes to the renewal and once someone has already signed and become a customer for a few years, we always end up working very closely with customer success. Customer success ends up using our product very heavily because a big part of our product is also observability. We’re able to offer a lot of details on what has gone wrong with the integration. We have a lot of tools that allow a non-technical customer success person to ask any questions and answer them as well if a customer has come in and claimed that data is not coming through, they’re able to do a lot with our platform. So what we’ll do is we can join SKOs, we’ll do sales enablement training. We have a lot of materials that can help customer success team members understand what’s going on with the integrations. But yeah, we’re heavily embedded with customer success. And that’s really the goal. It shouldn’t be an engineering problem long-term. Customer success should be able to manage these integrations.
PR: Interesting. So taking engineering out of the equation. I’m just thinking, as you’re talking, I’m thinking, man, once you’re hooked in with Merge, how on earth do you leave, right? Because I imagine you have a fairly high retention rate. Is that fair to say?
SD: It definitely is a long-term relationship and that is also why we take the POC very seriously. Every customer has to go through a POC with us, and we also reject customers as well because we find that we can’t make them successful on us, and we don’t want that to be the foundation of our relationship as well. So yeah, we do have a very intensive POC process. You have to test us, you have to have logged into the platform, you have to really be confident that Merge can fulfill your use case because it is a long-term relationship.
PR: What would be a reason that you would reject a customer?
SD: They want something that’s just not possible to the platform or they want something that’s not possible via API. So sometimes, we’ll see people wanting to post deductions or post payroll runs. And it is possible with one or two payroll platforms, but it’s not broadly possible in the industry. And so if you’re planning on using us for that, we’re just not going to have the expertise for it. We’re also not going to lie to you and say that like we are the best solution for that. So we usually try to be very upfront with people, but if that’s like the number one thing that they want and they want that functionality across every single platform, even when it’s not available, I just don’t want to ever make someone feel like we’ve misled them. So we’re very upfront about it and we do reject customers.
PR: Interesting, interesting. Okay. So then, what about the different use cases? We talked about HR. Are there other areas of fintech that you’re making inroads into? I don’t know of one fintech company out there that doesn’t need any API connections, right? And fintech and financial services are very broad. Are there other specific use cases that you’re focused on? Or are you just focusing on the entire segment?
SD: We are very focused on expense management, AP use cases, AR use cases, and just making sure that we can pull transaction data as well. We’re starting to see some light FP & A use cases in financial services, but it’s still mostly startups that are focused on FP & A and pulling general ledger transactions.
PR: I mean, can you work with real absolute startups who have, you know, maybe two guys in a garage somewhere, or do you really want a company to be a bit more established before you work with them?
SD: We absolutely can, and you can sign up for the platform today and get started for free. But we are the most expensive platform, and for a reason. We have the highest quality products. We also have the best customer support team, and our customer support team is very, very, very good. So that does cost money. We are not like a fully PLG self-serve platform where you can just sign up and not get any help. Usually, our customers do need assistance, and we’ll want our customer success team to be involved. And so because of that, like a lot of times, much smaller companies will opt out.
PR: Okay, okay. So then we touched on this, but what human elements? I mean, you talked about, you have to do a POC, you want to get the customer success teams involved. It sounds like for a technology company, the human element is super important to you.
SD: It is super important, because what ends up happening is if you end up purchasing Merge and your customer success team or your pre-sales team doesn’t understand or is scared about Merge, then you never get any adoption. And so what our sales and post-sales team has to do is we have to go on-site, we have to train the sales team, we have to train the post-sales team. We also have to teach them how to use our observability tooling. So it really is like a very involved process. We’ll be very embedded with the customer success team. We’ll also help the customer success team teach their customers how to authenticate and onboard off the integrations, especially because the more enterprise you get, the more complicated it is, the more steps there are. And there oftentimes can be a lot of points of failure when it comes to authenticating and providing a good customer experience. So that training process and that human touch is very important.
PR: Okay. So then are your engineers adding new integrations like every week? How does that sort of process work as far as adding someone brand new into your system?
SD: It depends on the week. Some weeks will really focus on adding new integrations. Other weeks will focus on the quality of the existing integration. It kind of wavers depending on the time and the customer demand. But yeah, the process usually will be we’ll get access to a sandbox account, we’ll then plan on road mapping it, we’ll build the integration, and then we also go through a testing period. Then once it’s released, it’ll go into beta, and it takes a bit of time and several data points for us to bring an integration out of beta. If it’s an SMB platform that doesn’t have a ton of edge cases, we’ll bring it out of beta once we have a certain number of customers. But if it’s an enterprise platform, then we start looking at the number of bugs and also the number of customers onboarded, just because the stakes are much higher. And if it’s an enterprise platform, our customers are then also onboarding an enterprise customer as well, which means that the room for error is just much lower.
PR: Right, right. And so what happens when something breaks? I mean, cause you have to be, you must have engineers on call 24/7/365, right? Because something could break on Christmas Eve, and, you know, you still need to fix it, right?
SD: We do, absolutely. So we’ll either be notified ahead of time. Oftentimes we can see that something is broken or a sync has not been running, or customers will also notify us and say, like one of the customers is claiming the data coming in is not correct. I’m looking in logs, I’m also seeing some issues, and then we’ll start investigating.
PR: Okay, so then, and we touched on AI earlier, I’m just curious if you’re using AI internally. A lot of tools have been added for developers to help make their jobs more efficient. I mean, what are you doing internally to help make Merge more efficient?
SD: All the time. We’re really, really pushing the entire company on using AI. So everyone, whenever they have any questions, they’re highly encouraged to use Notion AI. We ended up signing on with Notion AI a few months ago. It’s really been a game-changer for our team. Every single person, if there are any questions, contacts us in there. And we’ve also been getting much better at documentation in Notion as well because of that.
PR: So you said before that you really do one thing and you do integrations. Are you going to stay in that lane? Where are you taking this company? Is this going to be the focus for the foreseeable future?
SD: The focus is really customer data. So integrations is one way to get customer data, but there are other ways as well. There’s SFTP, there’s CSV upload. We can also get data from a data warehouse as well. So our goal really is that wherever your customer’s data is, we’re able to help you pull it and we can also load it into wherever you want it to go. So we’ve got like one part of that from, like, the data source side and then also one part of that from, like, the loading part, which is just the right API. But eventually, we want to make sure that we’re able to be much more flexible, so wherever your customer’s data is, we’re able to help you out.
PR: So what about governments? Are you doing work with state governments, federal governments? I mean, a lot of them probably don’t have APIs, right? But I’m curious to see if there’s any demand there.
SD: Not right now. We haven’t really started working there yet. I think we would probably need to start working more with security companies before we end up working with the government.
PR: That’s fair. So what about those companies that don’t have an API? I mean, do you help companies that are just sort of getting started that want to be on the Merge platform, but don’t really have their API developed yet? Is that part of what you offer?
SD: We absolutely do. There are quite a few startups that will launch, and they want distribution because we’re also a distribution point as well. So, for instance, every time we add a new integration, automatically a lot of our customers will have it enabled in their platforms. It’s a really great way for new companies to offer integrations with more platforms. So we do help a lot of companies with their APIs, designing it. A lot of them will actually model their APIs after ours, which is really flattering and makes it a lot easier, too. But we also work with much larger companies too. So like Justworks, for example, didn’t have an API, a very popular payroll platform in New York City. And we helped them design their API. And we’re building into it currently, giving them feedback on it as well. And so once that’s live, then all of our customers will have access to it, too.
PR; Really interesting. Well, Shensi, I really appreciate you coming on this show. You’ve created quite a unique company here, and one that I can see has tremendous potential. So, best of luck to you.
SD: Thank you so much. I really appreciate you having me.
PR: One of the things I found most interesting in this interview was how much human involvement there is in what is ultimately a technology process. Shensi talked about the importance of gathering the different teams together to ensure that the integration is understood, not just by the engineering team, but by the customer success people at the client. These are the frontline people dealing with the end users, and it is smart to make sure they are not just on board with the process, but they understand it intimately, so can answer end-user questions. As Shensi said, this should not be an engineering responsibility. Customer success should be able to manage these integrations.
Anyway, that’s it for today’s show. If you enjoy these episodes, please go ahead and subscribe, tell a friend, or leave a review. And thanks so much for listening.