The Exchanges

Q So Flatfile is interesting. They're raising a lot of money very quickly. We're basically saying, listen, if you rely on data from your customers and a CSV upload, like use this to quickly do it to map data, you're saying, Hey, if your customers don't have a CSV upload, just use our API integrator, let them connect directly to the API. How do you think of yourself compared to Flatfile?

A So we are actually very close with Flatfile. We are a customer and their CSV upload is embedded within our Platform. So when customers are going through that linking flow, they can actually come in and, you know, select from the different ATS platforms or HR platforms. And then the last one is CSV. So that if someone has an internal platform or they don't have API access, some platforms charge for it and they don't want to pay for it. They can ultimately just export a CSV, upload it with us. We still, we use flat file to do all the sanitization and normalization or not normalization, sanitization. And then we pump that through our backend to normalize. And it appears just as another integration called CSV.

AI assessment note: “We are actually very close with Flatfile. We are a customer”

Q guys, we're big fans of flat file. They love the show. I said, you got to give me and my listeners a great discount to try a flat file. If you guys want to take advantage of that, you can go to nathanlacka.com forward slash flat file. Gil pivoting here. So how do you think about the more sort of marketer friendly tools in this space, like sort of Zapier?

A Yeah. So, so those platforms, we don't, we don't think of as like competitors. We don't, we don't view them as similar products and we don't really run against them in a sales process. Um, so those, those platforms are really good for connecting. We see, we see those are horizontal integration there. They like to connect disparate systems. So something happened on Salesforce, notify the sales team on Slack, whereas we are so, so sorry. So those two are vertical agnostic. We are vertical specific. So we make sense of the data and normalize it into a single format. So if you wanted to accomplish something like adding 30 ATS integrations or 30 HRIS integrations to your customers, your customer would ultimately need to buy Zapier or Trey or Workato, and then go and build out each of those 30 integrations. And it's ultimately just moving from code to a UI. And so engineers actually prefer to just code. Um, so, so we, we generally don't run up against those ones. They also just don't go as deep with the data. You know, we're, we're really covering everything that APIs cover. And even if we don't normalize something with merge, we have, we have, uh, tools that you can use to make it so that anything that's possible with a native API building directly, you can do with merge.

AI assessment note: “those platforms, we don't, we don't think of as like competitors.”

Q They actually price purely off this usage metric. You're sort of doing this interesting test right now where you have, you know, one cent per API call, but also like a flat fee. Do you see a world where you're moving only into one of those? In other words, more, more like Snowflake where you're only charging that usage fee and is SaaS going to become irrelevant down the road?

A Yeah, no, I, I think we're always going to have two models. It's just unrealistic to expect a really small, even pre-funded or like early seed startup to front so much money for integrations and they might only onboard one or two customers. They really want to validate. And so while we don't view that as like, we do, again, we view that, that as pre-sales, um, and it really is a way for someone to kind of evaluate and onboard. So ultimately, yes, we do want to convert everyone to a fixed flat rate. We also want to give them the certainty. Like we found that customers like that. They like the certainty. We don't have a limit. We can just onboard as many customers as we want, sync the data as often as we want. We don't have concerns around it. Um, and we are also, you know, experimenting with it, uh, with the, the one cent per API request pricing model, but there always will be a usage based pricing as well.

AI assessment note: “I think we're always going to have two models.”

Q Yup. Now this is always an interesting question too. I mean, did you do some early consulting before you fully developed the actual productized version of this last year or no, you went straight for the SaaS revenue?

A Oh yeah. No, we went, we went straight for the SaaS revenue. Um, we, we were fortunate enough to, to fundraise early and we spent six months just building up the platform. Um, we didn't have a single integration. And then in January alone, we added 20 integrations. Um, cause all of what we built is around being able to really quickly add integrations. But also keep them up to date, make sure that nothing breaks. Um, we did have an API break on, on a Sunday at three AM because they had, you know, a breaking change that they released automatically and it broke hundreds of companies integrations with them. And fortunately our on-call got paged and our post-mortem says it was fixed by three Oh six AM. So we're pretty proud that we can, we can react really quickly as well and not expose any downtime or issues to our customers.

AI assessment note: “No, we went, we went straight for the SaaS revenue.”

Q right? At FounderPath, we rely on Finch data for payroll count. Uh, Finch obviously allows us to just embed it and then our users can connect to like Gusto or any of those platforms. You were basically saying, Nathan, if you replace that Finch integration with Merge, Merge directly talks to Gusto and Bamboo HR and ADP and all those things. So there's no need for Finch. Is that accurate?

A Exactly. Yeah. And we're, we're all API based only. So we're built from enterprise from the ground up. We're built to scale up to enterprises. So all API based, no scraping. We're not doing things like that. Um, and then again, a lot of the management tools as these issues come in, um, actually for reference at jumpstart, we would have, sorry, now canvas, we would have issues come in and I would go into my spreadsheet and take a day off of engineering days for each issue because it was a context switch. They had to dive deep into the logs, figure things out. So all the tooling we built is, is to help manage that. Customer success can handle customer issues, not engineering.

AI assessment note: “Exactly. Yeah. And we're, we're all API based only.”

Q Take me back to customer one. This is always tough for founders. Who are they? How'd you find them?

A Yeah. So it was, it was kind of an, I would say our first five to six customers onboarded at all around the same time. Um, and, and it really was word of mouth at the beginning. Ultimately we started using a lot of marketing. We go for virality with a lot of things like that. We're really big on social and all of our, you know, if we, if we build a new integration, it auto generates all of our marketing content and posts it across social. Um, so, so we're really going that way and that's resulted in a lot of our later customers coming in. Uh, but yeah, early ones were some friends, then that spread through word of mouth to non, you know, non-friends. Now I would say we're quite close with all of our customers or especially our early ones. Um, and then we, we really, we, we did kind of view them as design partners, but we also know that integrations are business critical. So there wasn't a lot of room to really make mistakes. So it was sort of like, uh, you know, they give us feedback, but we made sure that things were perfect before ever launching things.

AI assessment note: “early ones were some friends, then that spread through word of mouth”