An API for APIs with Gil Feig from Merge

Hi friends. Welcome back to API. As you won't hate, this is Mike, your co. For this episode, I'm chatting with Gil , who is the co-founder of merge.

I'm great. How are you doing?

I'm doing really good. Thanks. Yeah. So I appreciate you taking the time to chat with us or wanted to talk a little bit about you and merging your story and how all that applies to API APIs and the, the world you're kind of living in. And so maybe we can start with, a bit about yourself your background, perhaps, and how you got to where you are today.

Yeah, absolutely. So I'm Gil. I am a software engineer through and through. I've been been, so since I was pretty young, I had a computer in my room and started coding, but got serious about it in college, made her majored in computer science and graduated and went straight into software. So I worked at LinkedIn for a few years. Then Wealthfront. And then finally I joined a startup called canvas now called untapped, which is recruiting.

Yeah, Got it. Okay. So it sounds like you were living through the pain of something like many startup founders do and kind of saw that pain as an opportunity. So how long ago was that? When, when did you found merge?

Yeah, we started murders right at the beginning of the pandemic. So it was around June of 2020. Wow. Yeah, dove right into the deep end. Huh?

We did we, I mean, what better time? The opportunity costs of starting a company then was you either sit there in your room and do nothing or you start a company. So.

Yeah. Okay. So. That, that's how you got to merge. And you kind of said it already, but what's maybe the value proposition or the elevator pitch for why someone would want to use merge.

Yeah, absolutely. So when, when you're starting a company and you know, you, you know that you need to be data rich, I would say most startups, these days have some sort of data that they need to interact with. And, and even existing companies, large companies we sell to as. Basically come up with these product ideas. Like we want to build X, Y, and Z, but we need to pull in our customer's data from their HR system.

Sure. Yeah. So that, that seems like a pretty easy call, right? When the alternative is go ask one of your developers to become an expert on someone else's product for a little while or long enough to be dangerous, or maybe not even an expert, but to just go try their best to figure it out. And then maybe not have the time later on to go keep up with changes. Oh, when things break to go and update the, the implementation and have to worry about those details. So you mentioned one of your, your.

Yeah. Sure. So we first started with recruiting, which is ATS or applicant tracking systems and HR and payroll. Those were our two categories that, that kind of launched HR and payroll kind of being one joint one. So it's HR payroll, and then ATS, the reason we chose those. We were familiar with ATS. It's something I had built out extensively before ATS also comes with a lot of customizability and a lot of variation between platforms.

Yeah. Wow. All things that are in their own way, very, very customizable and a pretty significant problem to approach from a development standpoint. I think maybe the only way you could have taken a harder route in would have been to start with something like electric health records. But it sounds like you went with a good challenge to start, and it's cool to see that you've found some traction and whatnot. So for the API, you won't hate audience.

Yeah, absolutely. So I think for us choice of stack was, was more about speed to market. How quickly can we move? What is something that a lot of people are going to know coming in or something that people can easily learn as opposed to going for something that is the most optimized, fast language? So naturally we chose Python, which I think as we grow now, it is a bit of a slow language, but again, it lets us move incredibly quickly.

Yeah. Got it. And So on the other side of that, for your customers who are consuming services through merge, it looks like you ship a few different client libraries and, and a couple of different languages. Which of those do you support them?

Yeah. So what we did early on was was basically, we need to be able to move incredibly quickly. Everything we've done is about how much we can automate. And so we're using open API for our APIs to document them. I'm sure most listeners here know this, but a sort of similar to swagger or any model Jen that you have at had a lot of bigger companies where they build in house. But we use open API. Our open API spec itself is auto-generated using something called Django spectacular.

Sure. Yeah. That's probably the sign of a growing organization that has, has you know, multi-variable requirements to fulfill. But also one of those things where suddenly you don't have to go hire a Python developer and a Ruby developer and a Java guy and somebody who can do C plus plus and all these other things for people who want to consume in every flavor under the sun open API is a good way to scale that stuff out. That's really cool.

Yeah, it's been great. And I think, you know, there's, there's obviously some, some elements of it. Like when, when you stretch open API to its max, or when you stretch in general, like the rest spec to its max, for example, we support the expand parameter, which is a common rest, you know, sort of thing where, where we have certain foreign keys relations that come back as.

sure. Yeah. I'd imagine as you get clients using your tools that are running more sophisticated organizations, they want more of those things too. And you kind of stress test those those, you know, little edge cases of the API to.

Yeah, exactly. But when you have, you know, when you have 12 different languages across five different API APIs, that 60 repos, it can be pretty hard to stay on top of with a lean dev team. So.

Yeah, Yeah. To that end. How, how big is your team right now?

Yeah. So we are currently a total of 40 people. We have about 12 engineers full time, and then we have five people focused fully on building new integrations, using sort of a lot of the internal tooling that we've built.

Yeah, got it. Got it. so okay. That's, that's actually a pretty sizable team and it makes sense. Given the number of integrations you've got, like, I'd imagine you'd have to have a pretty, pretty solid standing army to just to build out new integrations, let alone keeping up with the old ones. When we're talking about the services that you integrate with, I know you mentioned that you started with sort of the applicant tracking stuff first.

Yeah, so we, we totally focus on market share here. We, we can obviously try to build ones that we want to build, but the most important is what people want. So with ATS, there's. Certain, I would say like looking at different market sectors, there's there's dominant platform. So in ATS you have greenhouse and lever that are really common among tech companies. But then we start selling to tech companies, right?

Yeah. Okay. Okay. You said something earlier that, that I kind of grazed over pretty quickly, but it's, it may be very interesting thing about the way it sounds like you run the company. How are you discovering what your customer is? How, how are you picking those next integrations? Like, is there a strategy for asking for feedback on those things or is it something you're discovering through maybe the sales process or, or I don't know, help desk ticketing, something like that.

Yeah, absolutely. So essentially with all of our, all over our marketing pages, our landing page. We show which integrations we support. And whenever we do, there's always a button next to them that says request new integration on top of that on our two premium plans or two plans that people are committing to annually, we include building new integrations at no extra cost. So we just say, get us an API key from a customer or a, you know, a sandbox key from a customer.

Yeah, that's ambitious. That is quite the strategy. That's very cool. Do you ever find, you're asked to integrate with something that is just not ready for the kind of integration you're looking for?

Yeah. So there's, there's a few different cases that happens in number one is they don't have an API there there's a lot of value in that. And we do have some ways of like, all right, we can try to integrate with reports as a service. And we, we do support doing that, but some really don't have an API. And if there's something that no one's really requesting, we're just not gonna, we're not gonna do it. Other ones we've been asked to actually help customers or help companies design their APIs.

Yeah, I don't really cool. Do you provide a backlog of, of integrators that you're hoping to implement next?

We do, but it's really funny. I know, I know it sounds a little hard to believe, but in general, our backlog is not new integrations. It's functionality. We are, we have 12 engineers and they're not even building integrations, right? That's our, that's our platform team. And they're just incredibly fast. We've gotten to the point where we can build most new integrations unless we're heading something crazy.

Sure that for off the cuff, having never really done this myself, that sounds pretty mindblowing. I would expect a scale of, I don't know, at least a month, a two to a couple of months for the integration in QA and then release kind of thing. So it sounds like you're moving really fast and able to work with, I mean, loads and loads of providers for good reason. You, you must have a really good process for doing that. That's that's very cool. That's super impressive.

Yeah, absolutely. I mean, we like to say we've seen it all at this point. I eat like 15 different types of auth. We've seen people implement ooff, you know, oh, up to like 12 different ways we found security vulnerabilities and how people implement it. So our tooling is basically. If the company, you know, we have, we have a pretty guided, I would say process to help people on board. And it's like, what is the name of the field that the access token comes in?

Sure. Yeah. Built from all the little scars and pain points you've experienced in the past. No doubt.

Yep.

Yeah. Cool. So let's talk a little bit about API APIs. In general, I'm interested in your thoughts on since you, your company has integrated with and consume so many API APIs what to you makes up a good API one. That's good for developers to work with.

Yeah. I think thinking about. First of all just being consumer first, thinking about what applications there are people going to use your API for and creating good access patterns around that data is, is really critical. Anything to avoid people having to make a ton of API requests you make end queries. And of course, obviously I think, I think before any of this actually comes just really great documentation.

Sure. Yeah, Often the special sauce when you're implementing with anything is kind of being able to read and understand what you're looking at. And honestly, frankly, kind of an overlooked career path too, right? Like really, really good technical writers who understand the problems that are being solved and can eloquently describe what's going on. And also accurately is it really, really special when you're working with an API.

Yeah, it's true. And it's so it's like great technical writing is really important. The other one is just the story or the journey of your docs. You know, it's, it's really underrated and people aren't thinking about the path that developer's taking there, but if, how you, if, if the method of authentication is the last thing in your. You know, you're, you're kind of guiding someone of path pathway having to click all around and go all over.

sure. Yeah. I, I lack of sufficient term to describe this, but almost the user experience. Learning how to build with something is underappreciated in the industry in general. There's definitely companies, organizations with huge budgets who can go And spin up a UX researcher just to work on docs, but that's often not the case.

Yeah. And it's funny because companies are willing to invest big bucks in optimizing copy on their landing page. Just not people from, from bouncing. But what about stopping developers from bouncing as they go through your docs?

Right. Yeah. Yeah, definitely. Yeah. We, we sometimes fund the wrong things at the wrong time, I think. So okay. I'm interested in any challenges that you've faced in sort of building this unifying API service. Is there something that stands out to you along the way that you, that you've taken away? Um,

Yeah. So I think you can, of course look at all the differences in authentication and pagination and, you know, rate limits and all of that. They're solvable, right? You just build things around them. I think what is hard is what we describe as the mixed functionality problem, which is that ultimately we can't define one, the functionality of the platforms that we integrate with and two, what their API is exposed.

Sure. Yeah. Are you finding that you need to demonstrate to people who end up buying your services that they're getting ROI, or is it something that is kind of proving itself once they get into implementation?

Yeah. I mean, I think first of all, for us, we only add value. What merged does is revenue generating. First of all right, you, you need certain integrations. You don't have the capacity to develop them out. You need those because you need to support customers who are on them. So by having merged, you're able to close those new customers. And then on top of that, you're saving developer time. So it's revenue generating and it's costing.

Yeah. That's a perfectly into my next question of how do you know in general, if you're building something that people want.

Yeah. I mean, I think for us, it was a bit easier because Shamsi, my co-founder and I both came from backgrounds. We would have used those. Right. And so, so there was a little bit of bias of us coming into this being like, all right, well, we both needed this and we both wanted this. And so we, we also spent about six months before we started the company talking to, we talked to over a hundred different startups in, in a bunch of different verticals.

yeah, sure. Along those lines then when you're when you were first starting out, so you talked to a hundred customers, you spent six months kind of researching things. Did those 100 startups? Sorry. Did they end up being your sort of first customers or was there something else you had to do to kind of get the word out there? That merge was open for business?

Yeah, they, they definitely, I would say a good number of them did for sure. And we actually still have close them. I think we, we fully remember it. My co-founder tweeted about this recently, but there were three out of those hundred that were, were very discouraging. That's always going to happen, but we're like, this is a terrible idea. Don't do it. And I think it was as of like two months ago, all three are now signed customers emerged. So very, very validating. And then that felt.

Yeah, that's amazing. I hope you pop the champagne or had a nice lunch that day. Something like that. That's really.

Yeah, it was really exciting.

For a follow on to that is how has your strategy for acquisition of new customers changed since your initial launch?

Yeah. So, so we still continue to do a bit of outbound. We're more inbound and outbound though. Word of mouth is a big one. I would say we're hearing about, you know, a lot of our customers are coming in now saying, oh, we heard that, that, you know, this company is using. We have to a lot of competitors thinking about how their competitors are building and, and, you know, wanting to get a leg up or wanting to at least have the same advantage that they have.

Yeah, Cool. That's really cool. It's it's you've built a lot of momentum inherently in the process here. Let's say tomorrow you were starting from scratch again and you were gonna build a new API first company, whether it was merged or something else that was sort of APIs at its core what are the things you would do first?

Yeah, it's interesting. I want to say, like, I would choose a more, more performant language, but I actually don't cause, cause the fact of the matter is we constantly had to just pivot and change how we were building and you know, doing Django and Python at Elta enabled us to move incredibly quick. We've been able to really scale with that. So I wouldn't change, you know, choice of language or any technologies.

Sure. Yeah, For whatever it's worth from where I'm sitting, that sounds like a great optimistic task and also something that would require you to become an expert on a hundred new APIs which takes a lot of time. And you may never have been able to get things off the ground, you know?

Yeah, it's true. It's a balance. And yeah, I say that now, going back when we were sitting there with no product, just sit there and spend potentially two months going through a hundred APS and deeply understanding our off. Probably not. So maybe getting an expert, someone who's built a hundred integrations, but that's also tough. Right? Who's done that. I mean, I had, I had already built several and I think we still, we still just constantly see new things that we haven't seen before.

Sure. Sure. Yeah. Oh, that's all very interesting. You you've had quite the journey kind of from gosh, 2020. I mean it's two and a half years or whatever, something like that to this 0.2 years, roughly. That's. That's a lot of first of all, a lot of implementation, but also a lot of lessons learned that it sounds like you're speaking from some really good experience and have built a really fascinating product. What, what haven't I asked you about merge that I should have asked.

Yeah. I mean, I think, I think one thing that we find really interesting is just how people actually use versus what the customer use cases are. They've been, they've been really exciting for us. I'm happy to dive into that a little bit, but I would say they they're very varied and I'm glad we went in with this mindset of, you know, we want to provide the data. We don't want to provide any. Information on top of it.

Yeah, those are really creative and they, they provide some special, like magical solutions to modern problems too, that you definitely need to tie into lots of things for it to make sense, to even try something like that.

Yeah, absolutely. And what's interesting also is just that, that nowadays as, as a consumer, you expect everything to be integrated deeply. Like when when, when you're buying a platform and they're like, all right, well, whenever someone joins come add them and invite them here, or, you know, whenever someone does. Whenever you close a sale, go out in Salesforce, but also go add it in our platform. No one wants to do that anymore. And no one expects. Everyone expects that your systems are.

Yeah. Yeah what about other verticals? So are there other other verticals that you're dying to get into, or that are interesting to merge?

Yeah, we do have other verticals for sure. And we can build very quickly. What's important to us is that our customers have a great experience. So since we're B2B, we're actually B2B to be all of our customers also sell to businesses, of course, right. Because these are B2B tools we're integrating with. And so it's, it's really important to us to give them a good experience because their customers are probably paying them.

Yeah, sure. Yeah. I figured you might not be able to share kind of what's coming, but it couldn't hurt to ask there.

Yeah, I think there are some good ones and some ones that developers especially will be really excited about.

Yeah, Cool. Cool. Well, we'll have to keep an eye out for news. And along those lines if our listeners developers are interested in following merge and keeping an eye on merger, trying out merge for their product where should they go?

Yeah, absolutely. So a merge is it's free to sign up and just get started. You can, you can go to merge.dev dev. There we have, you know, really good guides to get you started to help you dive in. And you can start with any of our categories. It's you get a hundred dollars a month for free. So it's really easy to just have.

Yeah. got it. Are there interesting sort of first integrations they can try?

Yeah. So a lot of our integrations, we actually listed there, but a lot of our integrations have free trials listed. So like bamboo HR is a great example. If you, if you go in and just sort of look at a bunch of the platforms there, you can just click on them and we provide links to the free trials or instructions on how to get a demo account. And then also, you know, again, since, since you know, any listener who'd be interested, likely works at a B2B company.

Yeah. Cool. So there's, there's a value prop in itself of just being able to get in and try sort of the whole full fledged thing with free tools. That's really interesting and I'm sure lots of the folks that will be listening to this podcast are more on the, Hey, we need to integrate with this side of things as well. What sort of things are you interested in hearing feedback on from our audio?

Yeah, we, we would love to hear, you know, we are a developer first company. We think that's why, you know, we're, we're winning among developers is, is everything we do is focused on deaths. So we want to hear about the experience we want to hear about onboarding was anything confusing in the journey. We want it to be as clear and as simple as possible. We're developers building for developers.

Yeah, you'll, you'll be surprised to hear that our audience is not shy about sharing their thoughts on things. So hopefully you get some good feedback there. What about hiring? Are you hiring for. any roles right now?

We are absolutely hiring. We are hiring for virtually every role across the board. We have grown incredibly fast. We went from zero to 1700 customers in under a year. So we, yeah, so we're really looking to hire we're hiring back end engineers software back at, sorry, back end front end, full stack. Definitely across the board there.

Cool. And just for sake of completeness, cause I know someone will ask me, are you hiring remotely or you're hiring just in a specific location. How does that work?

Yeah. So we're, we are in person we're in New York and San Francisco and both offices are where we're open to. We were remote flexible. I would say we, we, you know, we like to say we're kind of pre COVID, you know, your packages are, you want to work remotely for a week here and there. Totally fine. But in general, we are in.

Gotcha. Cool. Okay. So that's a bit about merge. How can our listeners find you if they want to get in touch with you?

Yeah, absolutely. So you can feel free to email me gil@merged.dev dev. Follow me on Twitter, Gil FEI, G Gill fag or, you know, also send me a LinkedIn.

Heck. Yeah, I will stick all of the relevant links and URLs in the show notes for this and make sure that they're posted when the show goes live here. It's been really fantastic talking to you. I appreciate you coming and spending some time with me and sharing about your product experience. Yeah. Thanks for your time. It was great chatting.

Thank you so much for having me