An API to abstract everything, with Roy Pereira from Unified.to

[00:00:00] Mike: Hello and welcome back to APIs You Won't Hate. My name is Mike Bifulco. I am one of your co-hosts of APIs You Won't Hate. And today I am hanging out with my good pal, Phil Sturgeon. Phil, how are you doing today?

[00:00:11] Phill: Hello. I am good. I'm in the Netherlands and it is beautiful and sunny, and there are sailboats going by the window. Fantastic. How you doing?

[00:00:19] Mike: There we go. I'm doing good. That means I can update the map I have on my wall of where is Phil today. With a finite location for once, which is always a, a positive thing for me. I'm, I'm home in North Carolina right now and have been en enjoying a fairly stable few weeks of, of life at home for once, which has been really nice.

[00:00:34] Happily, we are joined today by a new friend and guest of ours, Roy Pereira from unified.to. Roy, it's really nice to have you here. How are you doing?

[00:00:42] Roy: Oh, I, I'm great. I'm in Toronto. It's a little rainy today, but quite nice spring.

[00:00:49] Mike: Gotcha. Yeah. I've been to Toronto a handful of times and I'm always struck by both how Unbelievably nice people are to me, but also like needlessly maybe needlessly from my American perspective, but wildly [00:01:00] helpful people are, I think I must always look lost when I end up in Toronto and someone has always pointed me in the right way in a way that's like disarming and, and shockingly kind to me.

[00:01:08] Roy: Yeah, that's typically a Canadian thing. But it's funny cuz if you're from the rest of Canada, they'll say that Torontonians are brew. So it's, it is a spec.

[00:01:16] Mike: Well, fair enough. Like all things I suppose. So Roy why don't you start a little bit by telling us about yourself. And of course we wanna talk about Unified, but I'd love to hear about your career how you got to where you're at today, and the story of how Unified came about.

[00:01:29] Roy: Yeah, for sure. So I'm I guess what you call a serial tech entrepreneur. I like starting companies. I've started about five of them. It, it really started right after university. I was taking computer science university. I got really bored. I wanted to go change the world. I dropped out and I started a startup and realized after a couple of years that I had no clue how to run a business.

[00:01:52] So luckily I joined another startup, a real startup. This was during the.com era. We eventually got [00:02:00] acquired. That's when I also moved from coding into more product management as well. So that was really a great eyeopener. Yeah, I went to the, went to the valley, like a lot of tech people hanged out there.

[00:02:12] Came back to Canada. And, and then actually I did a bunch of publicly traded companies, which we won't get to. I'll try to forget about that. But went back into startup land, which is where I really love. And of I've been here ever since. I'm a very technical founder and CEO. But I have a pretty big range, but I love tech and this is how I typically start, I typically start about thinking of what's what I need in the, in the market that's missing.

[00:02:40] You know, that's the best way to actually start a company. Right?

[00:02:44] Mike: Sure. Yeah. So I guess that brings us then to the, the logical next step is what, what are you building now and, and what was the question you were asking that you're starting to answer?

[00:02:52] Roy: Yeah. It's interesting how I got here because when I look back at all of my startups, I really think I'm a one hit wonder.[00:03:00] I love abstracting data and abstracting APIs and connecting different APIs to do stuff. And each company does different stuff, right? I I, I, I like to do different industries and so forth.

[00:03:12] And, you know, I, I've done ad tech, advertising tech where I've connected different ad servers together. The last company was scheduling and we needed a bunch of data to schedule meetings with people. And so we did a bunch of integrations with our customers accounts like CRMs and so forth. And so I, I keep doing the same sort of architecture in terms of building out these integrations to third party APIs.

[00:03:39] And so I my last two companies were acquired and, and then the last one I was working for the acquiring company and I was thinking about what I wanted to do next, and I wanted to build out yet another SaaS application. This type was gonna be for salespeople to do something the relevant order was gonna do, because I started thinking about all the data that I would need to actually build this, this product [00:04:00] and data for my customers accounts.

[00:04:02] And it, it really upset me cuz I just had done a bunch of these integrations, not just at the last company, but the previous company before that too. And I was like, I can't do another Salesforce integration. I just can't. And I, I just hit a wall. And, and Salesforce was the one that hit me hardest. It was like, no, I can't do that.

[00:04:21] It's just like getting paid me every time I look at that API documentation. And so I actually put it on hold and I said, you know what? I'm just gonna enjoy my summer. I'm not gonna even think about that as too difficult. But then I started talking to colleagues, CEOs and CTOs and they were telling me how much of a pay that is actually.

[00:04:41] And I was like, I know, I know it's a pay. But I talked to a CEO that basically said, it's not just a pay, it is a revenue limitation. I can't get my engineering team to build another integration to say HubSpot or some other crm. And our revenue has been impacted [00:05:00] greatly. And that's when the light bulb moment hit me.

[00:05:03] And that's when I went back in. I said, this is the product that I need to build. I need to build a developer tool. That allows SaaS applications to easily build in these third party customer facing integrations. Because in today's world, it's all about data and the data's everywhere. And you don't own that data.

[00:05:24] You are not the source of truth, right? And so there are existing sources of truth out there, the, the sales forces of the world and sales world workday for HR and so forth. And so the pain that I was feeling in terms of building a new company I turned that around and I said, I'm going to productize this concept and allow other apps among the other SaaS companies to easily integrate this unified API into their infrastructure, their product infrastructure, so that they can offer these customer [00:06:00] integrations without spending a ton of time and money.

[00:06:03] Mike: I think that is the sort of thing that if, if you've built things from scratch or been on teams that have had to develop new arms of a product, you find yourself answering the same questions over and over. And maybe a good litmus for that is are you adding the same, like, am I adding 12 a p i key environment variables to my project?

[00:06:19] It's probably scratching an itch that's, that's somewhere similar to what you're doing at Unified. And in the end, I think all of the, I don't know, pick you, you pick your choice. CRM management, mailing list management error management, all of those things tend to feel the same. The APIs are similar, but they each have their own quirks.

[00:06:35] It sounds to me like the goal of Unified is to give people the opportunity to do that without having to think about each API individually. Is that more or less right.

[00:06:44] Roy: Totally, and we actually have that written. It's like we should get tattoos on that because that is our ultimate goal, is to not have our customers, the developers read third party API documentation. So we want to unify as much as [00:07:00] possible for the greatest amount of use cases so that our customers only use us, only look at our API documentation, our SDK documentation, all of that, and never have to go and read a Salesforce API documentation or Workday API documentation and not really care what the difference between HubSpot and Salesforce is.

[00:07:21] Because in, in a unified a p I environment, that should not matter.

[00:07:25] Phill: So I was just having a look at this and that, that, that felt weird in itself, that I actually, you know, prepared Sure. Podcast styling. But I went through and had a little play around and it was well helpful. I, I couldn't quite visualize how this is gonna work, right? Like, oh, it's an API that's distracted.

[00:07:40] Everything else ever Is that, is that helpful? But looking, looking at the way you set it up, you kind of got integrations just like it's Zapier or something like that.

[00:07:48] Roy: It, it's called Zapier actually, cuz it rhymes with happier. I was told.

[00:07:52] Phill: Yeah, there you go. I've heard Americans say Zapier and I always what to complain about that, but Fantastic. But yeah, you kind of set up your integrations and the coolest [00:08:00] thing I noticed was that it was like, do you want to use your owno or tokens or do you want to use ours? And I was like, oh, I could like integrate with discord, for example.

[00:08:08] Without, without actually having to go and register an application and set up all of my config and do all of this stuff. I could just use your keys. And then what? So when the users of my application want to connect with Discord, there's a little button that you've generated with a single line of Gerald trip to you in bed, you click on that and it opens up the whole flow of like, Hey, why don't you go and connect with Discord using our tokens?

[00:08:31] That, that just cuts out so much time. Yeah.

[00:08:35] Roy: Yeah, we did that because we, with that time to the the aha moment is super important in any, any product, but as a developer, You have so many choices, you are Googling, how do I, you know, do x and you don't have a lot of time because you're on a sprint, right? And you have like a two week sprint cycle.

[00:08:54] And so if you can get to that, ah, this does what I need to do. And so what we [00:09:00] wanted to, to allow our developers customers to, to do is to utilize our, our unified a p i to test it. And so we actually went out and we got all of our AWA credentials, it's called technically so that they can actually use ours.

[00:09:15] Would they launch their product with ours? No. And in fact, you can't. Or you shouldn't. But it is a great way to test and to play around with the system. Most developers are great developers cuz they play with stuff right? Until they, they're comfortable with it. So that's what we wanted them to do.

[00:09:34] Phill: Yeah, exactly. I mean, if I'm, if I'm trying to sit around working out, I mean, you were just talking about when you've done 10 Salesforce integrations in a row, but when you are that person who's just start starting to try and work out what CRM to use and you've gotta go and try out 10 different CRMs you've gotta set up Oh, or a credential for 10 different apps to see how they go.

[00:09:50] That is incredibly annoying. And its,

[00:09:52] Roy: It is, setting up o wall credentials is one of the worst things. That has not been fixed, by the way, [00:10:00] on. I, I think at some point we're gonna have to take a look at that. Or the industry's gonna have to come up with standards. It's, it's horrible and we get quite a lot of support calls from customers of developers who are sort of stuck, even though we have how two articles on it.

[00:10:14] Phill: yeah. Yeah. I mean, yeah, for sure. There's so, so much standardization involved in too, as, as to how the flows work and different processes work. But like, what's the, what's the user interface for it? Ah, I don't actually got out. It's Yeah, some, I mean, the way I've generally kind of gone about this problem in the past is using kind of installable packages when they exist.

[00:10:38] So for example, there's things like Omni or that can help my specific application in Rubion rails. You can integrate with a bunch of different like Facebook and Twitter and all these different old login things and it'll kind of generate some views for you. So you get a bit of interface kind of made up.

[00:10:56] Or we were talking on a recent episode about how there's lots of different, [00:11:00] like geo code APIs and you can find a, you can find a Geocoder php and it's got braver for 10 different, you know, APIs, things like that. There, there's been attempts to abstract certain, certain verticals all over the place. But yeah, there's pros and cons to having that as a SAS itself versus a bit of software that you are, you are controlling, but.

[00:11:20] Those are very niche, you know, or, and geocoded, like what, what sort of API is a uron abstract?

[00:11:28] Roy: Yeah, it's a really good point. Phil. So there's been I think some unification of APIs in the past that we've seen authentication for sure. So you have Okta Off Zero, you have Firebase you have superb base. They're trying to unify them somewhat, and I think authentication's pretty well done.

[00:11:45] I mean, it's a massive market. Okta is like 2 billion revenue in your year just for authentication. But if you go back a little further, you actually see now I'm blanking here. Plaid. There it is. Plaid unified API for [00:12:00] financial services, for transactions. How they were getting the data is a little different than what we're gonna talk about cuz we're all talking about APIs.

[00:12:08] A lot of times Plat was screen scraping sites bank sites, but what they represented to their customers, I know but their, their representation to their customers was a singular unified a p i. And I thought that was really, really interesting and smart. Of course integrating into, say B2B applications like sales and, and HR applications has been done in the past.

[00:12:35] I wouldn't call them a unified api I that much. There was a couple of companies like Cloud Elements and some others that have tried to do this in the last 10 years or so. But that unification was sort of lagging. And the issue there again is if a developer has to both implement your solution, but also read the p i documentation of the integration, And what sort of value are you really adding [00:13:00] there?

[00:13:00] So I, I think pushing it to it's, it's its maximum in terms of unification is super important for us. So to answer your question though, Phil, so we're really targeting on two, what we call clusters categories. The HR space with r i s performance management directories and ATS applicant tracking systems for recruiting.

[00:13:23] So that cluster is quite important for software companies that target employee benefits for example, or anything around an employee or anything around a candidate. And that seems to be a very large market around the world is about 15,000 or so software companies that, that do target that.

[00:13:41] And it's also a really interesting industry because there are clear. Sources of truth, these platforms that store the employee data, especially employees. So Workday, s a p y d P, all of those big older software companies that have the lions show the market. [00:14:00] And when you talk about, say, older or more established companies, let's call them more established, you typically are talking about an a p i that maybe isn't as modern as it should be.

[00:14:12] So it's very difficult to interface with, to, to integrate into your application and then to monitor and to maintain it. So that's one cluster that we target. We also target sales and, and, and marketing support as well. Those are also very important categories. There's quite a lot of sales software out there.

[00:14:31] If you think about sales enablement or sales cadences reaching out to prospects and so forth. Mailing list, software, all of that. Trying to get that customer to go through your funnel, down to convert and to upgrade. So those are the two that we target today. And of course, our architecture allows us to expand into others.

[00:14:53] We've had lots of conversations, you know truck shipping logistics for example, comes up [00:15:00] sometimes and it's like, oh, that may be a little bridge too far right now. Well, we are a small company. We wanna focus.

[00:15:06] Mike: Yeah. Roy, I'm really curious in hearing a little. About the story of how things got started. So it seems to me that one of the challenges with building a company like this is if you're going to unify APIs, you need to start with an MVP that tackles quite a bit of surface area From an implementation standpoint, what did the very first version of unified look like?

[00:15:24] Where, where did you start in this mess of unifying APIs across all sorts of industries?

[00:15:30] Roy: Yeah. You know, it's funny, we started with the architecture. So we're actually just five months old. We started in January-ish of this year, 2023, and we started with the architecture. We, we did the hard work ahead of everything else. And it was just based off of experience, you know, what did we do in the past and past companies?

[00:15:52] What worked, what didn't work? You know, we did some research into how much time we spent on integrations in some of the latter last companies. [00:16:00] Not quite a lot. And it wasn't just building, building actually was, I think the easy part in terms of time management. It was actually maintaining them. APIs change all the time.

[00:16:10] Things break, sometimes the API documentation isn't actually what the API has. And so there's all sorts of issues there. Oh, a p i keys expire and off credentials expire and so forth. So so we basically started with what do we know worked, what, what didn't work? And we built the core architecture.

[00:16:32] And what we found was it took a long time and we only really started building integrations in the last couple of months, to be honest. And those have been added very quickly now that we have the architecture. And so now we have 92 integrations that we've built out in the last. Two, three months. We're actually getting faster and faster at building them, but we also created, again, the, the core to also monitor and to manage them [00:17:00] after they're launched and after they're connected to a customer's account.

[00:17:04] And so that's super, super important to us because we don't want it to break and not know but also to our customers because they rely on, on our stuff working, right? And, and if it doesn't work, then why are they using us instead of having an internal team, for example.

[00:17:19] Phill: Yeah, this is something we were talking a little bit before we hit record and it was a combintion and we should have just hit record. But I was talking about how I feel like there's kind of, whether it's two binary types of API developer or a bit of a sliding scale I was talking about how there's kind of the people that.

[00:17:35] Just don't really care all that much about APIs and want to write the quickest, shortest, briefest happy path they possibly can, where they just get the thing and smash it through Jason's decode and hope for the best. And then there's the people who are often ferry places about APIs and want to build all sorts of wrappers around it so they've got a soft dependency and make that into a mapping service instead of talking to a map and get very kind of complex [00:18:00] about, about the architecture.

[00:18:01] And I'm wondering which end, which type of customers you are, you are aiming to target there? Because I feel like neither them, them be interested even though all of them can benefit from it. Like how do you wedge in against those sort of people?

[00:18:16] Roy: Yeah. You know, we're all developers, right? And all developers feel like they can build it, right? Product manager comes in the room and says, Hey, I need X. And they're like, yeah, I can build that. No worries. And even as you get more senior, you still feel like you could build it. I think maybe you have maturity and you say, well, maybe I'm gonna look at alternatives, build versus buy kind of thing.

[00:18:37] And so what we're finding our customers are the type that they've built it. So they know how much of a pain it is to build, but also the maintain. And really, again, that maintain part is really the, the thing that hits you, the tech debt and then the fact that you don't have time to build features, features in your product that are differentiate your product.

[00:18:59] [00:19:00] That's really killer cuz then you're disappointing your product manager, your ceo, your CEO's complaining of L lack revenue growth and so forth. So we typically get those types of CTOs or developers coming to us, and what we're finding is that they want to expand. So they just got asked to build x, y, Z integration that they don't have.

[00:19:21] They have like maybe one or two. And so they need to add in because the customer requests it. And so obviously the CEO wants it, salespeople want it. But they'll add that integration. But then they also will go back and replace their integration that they built natively as well, because once they get comfortable with the fact that this actually works better, the architecture is better done than their quick architecture that they did or lack of architecture.

[00:19:49] And so they are, they're really happy. Like you can actually see like a sigh of relief, especially when you're having these video calls, you actually see their faces and, oh, like, oh my God, I don't have to think about that [00:20:00] anymore. And so to answer your question, yes, they are like the typical developer that loves to build stuff, but is sort of reluctant to really go deep and, and to own it because it's not core.

[00:20:12] Like this is not what their job is. This is not what their product is. Their product does some other mousetrap thing that's cool and differentiates it. Talking to a customer facing API is like not sexy, and it's not really part of your core differentiator, but it's necessary. And so I think they understand that for sure.

[00:20:31] And so they're, they're quite happy to, to give that off. And yeah, I sort of equate it to nobody hosts websites anymore on a server in, in your closet. You know, we gave that up a long time ago. We gave that control up. It's like, Hey, you know what? I trust AWS or Azure or Google. I don't have to think about this.

[00:20:51] I'm just gonna let them do it. And now, you know, you saw. With plaid you saw with Okta with authentication, you know, Twilio with SMS and [00:21:00] voice. So there's a lot of examples out there. And so this is yet another infrastructure that we license, use a better word, but license I include in our products so that we can actually focus on our product better.

[00:21:14] And the developers understand this. They don't want to build this stuff.

[00:21:18] Mike: Yeah, it strikes me that there's a pretty good parallel for this that, that most probably even non-developers can relate to in. Photography that, you know, for a very long time, people who were into photography were the ones who spent their lives like studying photography and figuring out how to use a camera and like what an aperture is and buying the right film, or whether they're gonna be outside or inside.

[00:21:37] Then digital cameras came along and you know, we had a little more access to things like the, the equivalent to this might have been when services like Okta started appearing and maybe there were a bunch of choices and the APIs were a little clunky and whatnot. But what really made things go mainstream for all of us is suddenly we all have a camera on our phone and like the UI for the camera on your phone looks like the UI for the camera on my phone.

[00:21:58] And it looks like, you know, an [00:22:00] Android one and a Palm OS one and a Windows OS one and all those kind of look the same. And suddenly the experts on you know, authentication and payment and H R I S and all those other things can do their thing. While the people who just need to use them in their day-to-day work can benefit from it.

[00:22:14] And centralizing these sort of APIs and giving Maybe albeit a simplified a p i for some of these things really empowers a lot more functionality and broader adoption across the industry. What, what's the education side of things look like for you? Are you finding that the value proposition of like, you know, hey, maybe you came to, someone comes to unified for like a sales crm integration.

[00:22:36] Are they finding their way into other bits of api? I facets that you're unifying, say call centers or recruiting things like that too.

[00:22:43] Roy: so we call those clusters because they are sort of intertwined someone, or can be depending on the, their use case, right? So if you're just doing sales enablement, you probably just want the crm and maybe the enrichment APIs that we built. But if you're doing some other sales or customer oriented [00:23:00] software, something around the customer, You may actually want to track the call center activity on that customer along with maybe the mailing list.

[00:23:08] I don't know. So those subtexts can, can intertwine just like HR in in applicant tracking systems, candidates and employees. A candidate turns into an employee. So you want a good handoff. But those two clusters don't really merge or, or intertwine at all. We find but to, to answer your question a different way, we do have customers coming in, or prospects, let's say, who are looking for a Zapier clone.

[00:23:34] And we're not a Zapier clone. We don't compete with Zapier or no code. In fact, we are code, you know, it's an api. You have to code with the api. We make it super simple, one line a go, but you still have to code. You're a developer, Zapier Enougher developers. And we don't offer the automations that a Zapier does.

[00:23:54] And that's not our role. We're not an ETL either. We're not taking data from one database and putting [00:24:00] it into another database. We basically don't wanna add any business logic whatsoever. We want to give our customers the raw material making it super simple for them. But they are building a product and they are controlling their business logic the way they want to.

[00:24:16] If they wanna store the data somewhere, it's up to them. Like they, it's not up to us if we're not gonna offer that. We are just making it super, super simple. We're, we're focusing very much on this one problem space. I think the other confusion that happens is we got a lot of co prospects coming in that wanna manage their own customer sorry, their own accounts.

[00:24:35] So their own Salesforce account, they wanna automate their Salesforce account, moving data from it to something else. And that's really a Zapier use case again where you're managing your own accounts for your own business, not your customer's data.

[00:24:49] Phill: Yeah, I think if I try and make it a bit more concrete, cuz what I've, what I've said about it so far is like, you can skip over too and that's cool. But I have to think to, to talk about it a bit more. I, I was playing around with [00:25:00] it and, and I'm trying to think of like a, a similar kind of vibe and it, it reminded me of on ghost, I've be using Ghost a lot, the cms.

[00:25:06] And it's super cool cause like you sign up to Ghost and then it's just got this massive pile of integration. So you can click integrate, integrate, integrate, integrate. And then it asks me for my, or tokens as the user of Ghost. And then kind of Ghost doesn't really care about those integrations, you know, cuz they could just be running through something like you and then in the background goes, can be using all that data to, to match things around.

[00:25:26] So yeah, it, it, it's kinda like that, especially with the, with the handy little JavaScript. S D K or not, not sdk, the JavaScript one-liner that you've got. You can like have your embedded integrations. So I could be, oh, it all sounded very clever in my head, but if I'm building application like ghosts, right, and I need to add loads of integrations to it, I can just pick a bunch of your integrations, embed that one line of JavaScript, and then it's got that UI will built out with a list of all those integrations that, that my end user can then, can then click on and integrate their accounts with my [00:26:00] application.

[00:26:00] Yeah.

[00:26:02] Roy: It's all about speed, right? The developer doesn't wanna waste three months of their time building out an integration on the back end and then building out the front end user interface for their customers. Like all of this is common stuff. Like we're, we're even gonna come out with some other common widgets actually.

[00:26:19] I I, I won't go into detail, but how many other things can we standardize? That one line at coa? Just to back up, one of my favorite developer stories is I was running a, a startup and one of my junior developers came to me and said, I have a solution to the problem that you asked me to go and solve it.

[00:26:35] That problem was we were having a lot of fraud with our payment system, right? And so I asked him to go and find some anti-fraud solution and he, he is like, I found, I found an even better solution. It's a new payment provider and they have integrated fraud and we should switch. And I'm like, but we're using like the big payment provider.

[00:26:55] And I asked him some questions and, and he told me, well, it's a new startup out of Ireland. And [00:27:00] I'm like, oh, no way. Like what? Some new startup, we're not gonna put our payments through a new startup out of Ireland. And then he convinces me though, and this is the point, he's like, but there's one line of code that they gave me.

[00:27:13] Their documentation is beautiful and I used it. I got to it working within 10 minutes and let me demo it and it solves all of our problems. And that one small Irish startup was strike. And so from that moment on, I've been using Stripe and it's because of that one line of code and that stuck in my head.

[00:27:35] And so I wanted to have our developers have this one line of code that they can insert into their app for their customers and get it running and look like Rockstar. And so that, that's the, the background of that one line code. It's turned into not just JavaScript, but also react Component and a U J F component as well when building an angular component as well.

[00:27:57] Phill: I think especially for, you know, a lot of US [00:28:00] API developer pipes and sort of people listening to this podcast probably came from a mostly backend perspective, and I might hear a bit different, but a lot of us were kind of like doing backend and kind of vomiting something out to the front end and hoping someone would tidy it up later.

[00:28:13] Roy: I love that. I'm gonna, I'm gonna use that. I think exactly how I felt as well, but I think with age you sort of understand that you need some more balance. So yes, let's try and balance that.

[00:28:24] Phill: Yeah. Yeah. I mean hopefully that's other people too. Otherwise I'm just admitting to being a bad developer, but I definitely am not ballsack. And so things like Stripe, things like you know, even the Shopify buy button all these integrations that are just like this one line of code, it's not just the one line of code.

[00:28:37] I could write a hundred lines of code. It's the fact that I don't have to go at a front end for this part of it. Right? Like, think about talking about the integrations. You know, you've got your, you are building an application, you've got a list of integrations of a bunch of third party SA systems that your users want to connect with for whatever reason.

[00:28:53] Building the interfaith for that sucks hc, cuz you've gotta build this whole like, you know, create applications and, you [00:29:00] know, log in here and redirect back there. And then you've gotta like add some webhook URLs that all you're testing. And that's hard. Although we've done some podcasts about how to make that easier.

[00:29:08] And then you've gotta have all of the various different forms and different things and all of just, just that building that is time I could spend doing literally anything else in the world. So for the fact that you've taken that interface off my hands is a, is a huge value in itself.

[00:29:23] Roy: But, but let's talk about all the stakeholders involved here, right? So we're just talking about developer, right? Which we typically only think of, right? And backend developers, to your point, Phil, not even front end. Yeah, forget about the front end guys, but there's more. There's a cto. And the CTO cares about different things than the developer, right?

[00:29:40] They care about security, for example, massive, right? And if you're building an HR software company, you really care about security cuz you're handling data that is super sensitive. But look at support people cuz after you launch those poor support people are gonna have to ma to talk to your customers and like, Hey, I'm [00:30:00] trying to hook up to a workday.

[00:30:02] Something's not working. So they need, they need help as well. They need something, they need documentation. But even marketers, we don't even talk about marketing. How do we launch this thing? How do we educate the marketer to launch? What do, what do they say on Twitter or what do they say on their release documentation for this new integration?

[00:30:21] And it's not just one integration. Like when they add us, they get all of them. They get all 92. Today, we're gonna be at a hundred in a couple weeks, but, so they can launch all of them at once. And so that's a massive amount of information that they actually have to do the work on. And, and I would actually pass it that the developer is actually the, the lucky one in this case cuz they can build this in an an afternoon.

[00:30:47] The marketer is gonna have to build a ton of documentation and this support people are gonna have to build a ton of documentation and their FAQs to support all of these.

[00:30:56] Mike: I think that an important bit of additional context to provide [00:31:00] onto this story too is, so Phil, sort of cheekily mentioned before that I, I come to this world from a very different perspective. The reason Phil and I met is cuz he was the API developer looking for a, a, a front end full stack person.

[00:31:12] Clean up his, his vomit mess as I think he put it before. And that's honestly, that's how we met, right? Like he, he had a bunch of really interesting ideas and I was used to taking the data from the interesting ideas and putting it into a presentable, human understandable experience. And you know, if I, if I could teleport back in time and talk to Mike from a bunch of years ago, I think the biggest thing I've learned from then is that like, much like you don't wanna keep building Salesforce integrations, I really don't want to keep building login screens.

[00:31:38] I really don't want to keep building the same payment screen, you know, to, to like design the UX of how to put in a credit card number or something like that over and over. And I, I do think that coming from both angles of this, from a developer perspective, the value is there and it makes a lot of sense.

[00:31:51] And now in the world I'm living in now where I'm building a company and you know, I'm, I'm Roy also in the startup world these days. And requirements change quickly and [00:32:00] needs of the team change quickly and the thing that on fire the most changes very quickly and. I think if you turned to me and said like, yeah.

[00:32:07] And so the story to get your people plugged into the tools they need faster is a reasonably simple integration with documentation in one place with value proposition for help and security and all those things. Like that with the wisdom of time behind me sounds a whole lot like something that maybe I should be paying attention to and, you know, maybe perking up a little bit when something like that comes across my inbox too.

[00:32:29] Roy: Yeah. Yeah. And you, you're right. When you know you, you can build so much, and, and the, the requirements are never over your product. People will always give you new requirements, so you're always gonna be busy. Doesn't matter how much importance and time do you wanna spend on things and. I would rather spend time.

[00:32:48] So back to my previous startups, when I look back and I try and do learn from my mistakes, one of my mistakes is that I think we spent too much time learning stuff that was core, and these customer integrations [00:33:00] weren't core. I should have spent more time on working on feature sets that were core, that differentiated my product from my competition.

[00:33:07] So I wish I would've done more. I would've, I wish I, I had unified to to basically handle all of these customer integrations. So I didn't have to do that. And back to that one line of code. So it's not just the front end that's important. It's also the backend. We have, I think you brought it up, we have an s stk.

[00:33:25] We have a couple of SDKs. One is a TypeScript node that you can easily use, but you can use one line of code basically with that as well, to, if you wanted to go and say, get contacts from A C R M or employees from an H R I S system. It's basically one line of code as well. So we're, we're trying to make it as simple as possible for both the backend and and front end,

[00:33:46] Mike: So I wanna talk a little bit about the implementation side of things too, if that's okay, Roy, from, from a consumer perspective what is the hello world experience like for Unified, if I'm starting to integrate with my product stack?

[00:33:57] Roy: right? So our end user developers, [00:34:00] right? So they come in, they, they go through a little onboarding. We try to get them to see the data from the API as quickly as possible. There's a couple, a couple of things they need to do. They need to say which integrations they're interested in and and then play around with that one line of code for that embedded directory, right?

[00:34:18] So that shows like a matrix of available integration. So if they turn one on, they have one logo they can click on, that they can enter in an a p i key if it's that, or an oof. To screen right? Using our own credentials. They see, they visualize it through their customer's eyes. But once they authorize it, they also get a connection.

[00:34:42] And that's like the core object in our, in our platform, everything runs off of a connection ID and it's abstracted. It's just an id, there's no authentication associated with it. There's no integration type. It doesn't matter, right? And so from a developer, then they get to use that connection id we give them a [00:35:00] little bit of curl code, which they can just copy and paste into their terminal and it calls that api.

[00:35:07] It calls, get whatever employees, contacts, whatever that integration supports. And then they actually see the data in their terminal. And so I think that's really important. As a developer, you know, there's a lot of BS out there, companies that tell you that they can do X and it doesn't, or it's really hard.

[00:35:25] And so we want to make sure that they understand that literally within five minutes, they're gonna see data, real data in, in a unified a p i. And that data object that comes back is unified. It is, it is one of the core benefits that we work our buds off. We expand those fields to the maximum that we can, and they're always the same format.

[00:35:47] And so, as a developer, doesn't matter where I am, my customer's data's in, it's always gonna be the exact same format, unified data model. And that's actually how we start it though, abstracting [00:36:00] these data models away. That's one of our core, I think, benefits of this. And so that's what they're gonna see.

[00:36:07] And then once they test that out, maybe they're testing it with their own accounts instead of their customer's accounts. Hopefully. You know, then they, they have this roadmap in terms of launching testing and then launching it in, in production.

[00:36:21] Phill: How about change management? Literally no one's favorite topic, but I'm doing it anyway. So something that seems like a benefit is that if there's, you know, your. You as an application develop building an application around an integration with some third party, and that's third party releases version two and three and four.

[00:36:39] And they're not really important. They've renamed the methods for no obvious reason, and they've added a few parameters that you're not using. But as far as unified is concerned, like it's easy enough to update that integration so that I'm, I'm assuming that the, the users of unified don't really notice those version changes most of the time.

[00:36:56] But what happens when a big change happens and like the data [00:37:00] is different? Can you h how much length do you go to to kind of help maintain that interface? And at what point do unified users need to do something differently if there's a big change?

[00:37:14] Roy: Yeah, so. As you can imagine with the unified data model, not all fields are available for all of the integrations. And we try super hard. Like there are some times when one API call into our system results in about 10 different API calls to the software that we're targeting just because we're trying to collect all the data so that we can build our own unified object model.

[00:37:36] And so when those API calls change or they, their data changes, their format changes, whatever, our customers never see that. We do. And we actually have a lot of automated monitoring in place so that we are ahead of those changes. And that is of course one of our core benefits to our customers. They don't ever have to maintain that awareness.[00:38:00]

[00:38:00] We do. So we're super hyper vigilant about that, about these changes. And we're also looking at the data coming across. Again, API documentation is usually out of date. Compared to what's actually happening on this a p I server, right? As you talked about, the front end guys typically get it last. And then the marketing people get it last.

[00:38:22] And so there's this, this waterfall method where the developer is way ahead of everybody else, especially the API developer. So we do have quite a lot of automation to make sure that we're always ahead. But when let's say Workday changes their APIs or data models or anything like that, our customers will never see that change because we've already changed along with that.

[00:38:46] And we have this unified system. We do expand that model. So there aren't, it's, it's not always static. So we will add into the field, like, you know, we'll add compensation or whatever. But that's in addition to, and it's not [00:39:00] backwards breaking.

[00:39:02] Phill: Okay, so whatever nonsense, they're absolutely you kind, ofra or unified, a unified. To face that is using evolution more than whatever breakthrough changes they've gone with. Cuz there's, there's easy examples slightly contrived and silly, but the, the like usage of names I've seen in API before where they're like, we used to have first name and last name and we realize that's not how names work.

[00:39:25] So now we use name and they like literally somebody somewhere just writes a bit of code that says if first name and last name then mush them together to do name. And then you've got that covered all the other way around where they used to have name and they've gone, oh crap, we want to integrate with Stripe the demands first name and last name.

[00:39:41] So somebody somewhere has written a explode space. And, and that again, it's not how names work but people do that sort of stuff. Like are you doing that sort of thing as versions change in the background or are you asking users to say, Hey, the data model changed, can you update somehow?

[00:39:59] Roy: No. So we are [00:40:00] monitor. Doing that ourselves. And again, we've, we've automated that. I think the example that you just gave is a really good reason why you actually don't wanna build these integrations in house because you're basically building an, an architecture that is inferior and it's not, you're not really thinking that long.

[00:40:15] You're thinking, I only have this one integration to build. Product managers asked me to build Salesforce. I'm gonna build Salesforce and now I'm gonna cut corners. Yes. First name, last name. I'm just gonna like, add them, add the two strings. And then something changes and then your architecture can't handle it.

[00:40:29] Or you're asked to add in a second integration and then your architecture really can't handle it. So we've done the homework there. We're actually gonna come up with an infographic in terms of all the differences. You know, first name, last name versus display name versus, you know, API key versus olf.

[00:40:47] All of that's the differences. There are quite a lot of differences that. Are gonna make our head spin and are making our head spin right now. But we've automated an up a bit with our architecture that it, all of this works. Now [00:41:00] again, it's our responsibility to make sure that it is working. So if they do change first name last name to just display name, we'll fix, fix that before anyone notices.

[00:41:10] I think what we've seen though more often is that they'll change the object. So they'll go from like, opportunity to deal or something like that. And then that, that, that's a much bigger change because the data model's completely different and maybe the associations between the different objects that they have are now different as well.

[00:41:31] So that, that's a little bit more time for us to, to go in there and refactor that.

[00:41:36] Phill: Yeah, I suppose some of them, like I seem to remember Stripe doing something along the lines of changing payment into like charge and receivable or something. And that just like is a fundamental change to how it works. But I'm assuming that many of the integrations you've gone for have kind of settled down a bit.

[00:41:50] There's that, there's that like early startup, everything's being renamed every five minutes kind of period. And then there's that like, It's strip, we're not changing, it's every had a weekend mate. [00:42:00] Like there's, you know, it kind of settles down at some point to a point. And also if they're mostly around the same verticals, like a team that a lot of them are, you know, it's, it's person and company and, and they're relatively stable domains in that sense as well.

[00:42:13] Roy: Yeah, so part of the unified API theory is, you know, we're not only unifying the API endpoint, right? S RAAs based API endpoint, we're also unifying the objects. So for ex in the c RM space, some c r M vendors call them opportunities. Some call them deals. We've chosen to use deals, but it means the same thing.

[00:42:35] Same thing with company and account. And so we tried to unify those as well and we documented what they mean so that you can extrapolate if you know Salesforce, it's an opportunity, for example. And then of course the fields are also the same. So there's really like three levels that we try and, and unify, and in fact, there's even more unification.

[00:42:54] So authorization, we talked about a little bit of that with our one line of code[00:43:00] to represent the embedded directory to your customers. That's for authorization. You're trying to get their authorization of their account. Most of the oof inventors out there have scopes, permission scopes. They're all different.

[00:43:14] There's no standardization at all there. So we've actually gone ahead and unified all of them. We've standardized all of them, and so again, you as a developer, if you need access to contacts and deals, you don't have to go and read about what scopes you need and then put in custom scopes into our authorization directory.

[00:43:34] You just can just say, I need to read and write contacts, and I just need to read deals, and then we'll figure that out.

[00:43:41] Mike: Sorry. I was gonna say one of the most striking things about the product altogether, which is really hard to convey through an audio medium like a podcast is the documentation that you've put together, which is sort of a meta documentation of, like you said, 93 APIs. And I think if you're listening to the show, and this sounds even remotely interesting, a really interesting [00:44:00] activity is to go just browse API documentation on unified two to, and check out what this looks like.

[00:44:06] What in practice, what it means is there are you can look at sales crm, APIs, for example, and see a list of, I don't know, what looks like a dozen or more CRMs that are supported. And the really thoughtful way that Roy, your, your team has divine a A nomenclature that unifies all of those things in a way that's like human understandable.

[00:44:23] I really like that you've published these I guess it'd be like an entity relationship diagram of the way that you, you think of the types and how they interrelate here for the things that, that are surfaced in your api. I, and so you can kind of see regardless of the c r m you pick, for example there's a notion of a team and a user and that user might have an address or they might become a lead and turn into a user and things like that, which fully zooms you out from having to think about, is this am I using front or HubSpot or Drift or Intercom or all these other things that's just getting into the meat of like, what do I need to get done here?

[00:44:54] Rather than becoming an expert on the underlying principles that have been, you know, cast upon you by the people [00:45:00] delivering the software. Yeah.

[00:45:02] Roy: Oh, no, thank you Mike. You know, back to the Stripe example, their documentation is world class. It's always been the best API documentation. And you know, I'm not saying ours are, are that, but we really try and we have a new design coming out shortly and we'll always have one, but it just really super important to have it searchable detailed and go from the top where you see this UML diagram so you can understand how things work together, but also go right to the, the bottom.

[00:45:33] Like what is each field and represent and so forth. So we've tried to encompass quite a lot of data. There maybe too much, but I think as a developer you wanna have that optionality. You know, you wanna get in there quick, five minutes, boom, boom, boom. Oh yes, it works. But then like, when something doesn't work, you want to have the detail there.

[00:45:51] So we try quite, quite hard to, to to add that in. And the other thing I would say is after you build all of these integrations, like we have, I think [00:46:00] 24 HR, I guess, integrations right now, and we're building out quite a lot more of them right now. But after you really understand the commonality, right?

[00:46:08] There are quite a diff a lot of differences, but the commonality in how they operate and how the relationships work and so we're giving that back to our customers. This is our understanding of how these, these elements, these objects work together. And so I, I think that's the API documentation that I want our customers to read and not Salesforce or Workday or anything like that.

[00:46:33] Mike: I suddenly have this overwhelming feeling that you can unplug yourself and see the matrix of how all these things are actually planned from behind the scenes and like that, that you, you've got a, a fourth dimension of vision for these things that I would love to develop. It's really fascinating.

[00:46:46] Roy: You know, it's, I'll give you a bad dad joke. Okay. Like, I, I, I always tell people that my, my second language is api. Because I really feel like I can sit and, and understand an [00:47:00] API within a matter of minutes. And it's just because I've always done this, right? It's, it's, you know, 10,000 hours, right? And so if you, if you've looked at APIs all of your career, you sort of are looking for specific things, you understand concepts.

[00:47:16] So, yeah, I, I, I, I think this is the company that I think I've always should have built.

[00:47:21] Phill: I, I'm interested in the kind of, the way that you talk about it, you've unified these things, right? You kinda looked at lots of different companies and, and you've come up with unify nomen culture and I assume a team as well, not just you, but I'm wondering about things like standards. So schema.org is, is something I know that some of our listeners are super excited about.

[00:47:41] It comes up on Slack all the time, not less, not just Jason Schema. It's a different usage of schema. Schema.org is like someone's, a large number of people have sat down and gone through everything. They've got, like they've got person which has got a address, additional name alumni or Birthplace Death place.

[00:47:57] And then Place is is another [00:48:00] type which has various different events and coordinates and loads, properties, address, geo whatever, an organization which has address and employees and tax numbers. And I'm just reading random fields. But then they have really obscure stuff, which is like biochem entity, actually.

[00:48:18] People like, okay. And Medical Entity and a bunch of other things like that. So there's some really useful stuff and some, you know, potentially useful stuff to a tiny place of population. But if you thought about working with something like Schema to say, instead of like, this is what Unify think that, you know, this is, this is what you think a person should be, maybe.

[00:48:40] It could be your job to convert things to person and back again so that you are working with the standard interfaith that is standard. Standard, not your standard.

[00:48:48] Roy: Yeah. Yeah. So I, I have two comments on that. One is I love standards. In fact, in, in a previous life I was part of the I E T F, which is the internet standards body coming up with standards for [00:49:00] virtual private networking, for example. So I, I, I see how an industry explodes what you have standards and all of the companies within it can communicate.

[00:49:10] So I'm all for that, and I'd love that there's not that many standards for say, crm. And so we had to build and abstract away that. I think that will happen over time. There are standards like Ski Skim for example which is for HR user provisioning, which has a user object. It's not bad. But I think that the comment that I would make to your schema example is that if you make something too broad, too big, then it sort of loses value, right?

[00:49:39] And so if you, if you define a user object for everything, then it's too big. And so what we've done and, and you can take a look like, so there's there's actually a section on our API documentation called like user objects, which is like, Hey, we have a bunch of user objects. They're all called different things like contact or employee or candidate or customer.[00:50:00]

[00:50:00] They're specific to the actual use cases. So A C R M contact is different than a HR employee object, which is different than maybe a, a ticketing customer object. And they're done for a purpose. They, they share quite a lot of information field, same fields, they email that kind of stuff. But because they're for different use cases, they're gonna have different fields that are relevant for that use case.

[00:50:26] And so that's the, that's the angle that we picked. We don't wanna add noise by having this meta massive user object that contained everything other than the sun. So that, that's, you know, you can, we can argue whether or not that was the right way of doing it, but

[00:50:41] Phill: No, that's cool. I had to ask if I knew, someone would shout to me about why you didn't, you just use chemo.org if I didn't. So thank you for preemptively answering them.

[00:50:49] Roy: Yeah. No, I, I would love to use standards and I would actively promote and be active in defining those standards. That is something actually that we are looking forward to doing. At some point,

[00:50:59] Phill: [00:51:00] That's very cool. Yeah, I mean, it just, every time it's come up, like g stoplight brought it up a little while ago when I was working for them and you know, they've got customers that have 500 different models for a flight, and it's the same company, just has 500 different flight models, so things can get wildly varied.

[00:51:17] So they've kind of gone with the approach of let's help companies standardize themselves so that they have like one thing to represent a flight. And then once there's lots of different companies that re flights, then you can start to standardize those versus if everyone's got snowflakes in their own home, then it's, it's not gonna be something you cane.

[00:51:34] So that, that makes sense.

[00:51:37] Roy: you, you're right, you, you look like a company like Postman. Postman is, is growing very fast. Why aren't they trying to standardize some of these things, right? Readme Yo Spotlight, there's a bunch of these API management companies that are looking more at customer facing APIs instead of just internal APIs like the API management company like Kong.

[00:51:58] So I, I think we will again there. [00:52:00] I'm not sure that there's a standard s spot out there right now, but maybe, you know, schema.org for example, could facilitate that. And like I said, already, there's a skim that has tried to do that, although it's definitely not unified. There's quite a lot of changes and differences within each one of those invitation.

[00:52:19] Mike: So Roy I, I realize we've been chatting about your product for a while here. A couple of things I wanna touch upon is if some of the folks listening to the show today are interested in jumping in and playing with unified. I noted on your site that at the moment at least it, it lists that you are sounds like either pre-launch or in sort of an early access mode.

[00:52:38] What's the best way to get access?

[00:52:40] Roy: Yeah, we're I would say self launch. The entire platform is operational. It's very scalable, very, very secure. We're not storing any data. We have a ton of security functionality in there even to to store access tokens in your own database and so forth. But you can just self-register. It's we have a [00:53:00] free plan to test out the system.

[00:53:02] It's free forever until you want to launch you, you know, you want your own identity. You don't want unified's identity in your app. And so anyone can go to unified.to and no, we are not based in Tonga, the South Pacific Island of Tonga. But it is it's a cool domain short, but we also do have a promo code if you guys want to test this out.

[00:53:25] We're giving out three months free. And that that promo code is just APIs you won't hate 2023 all in capital, most basins. So that's a really easy way to to actually test this and put it into your product. And of course, you know, looking at our Twitter feed Unified underscore api, we always post in Twitter and on LinkedIn as well.

[00:53:49] And we try and post quite a lot cuz as you can see from our change log, we are adding a ton of new integrations and a ton of Features within our [00:54:00] objects, like new fields and so forth. So we've, we've definitely figured out a way to automate the building of integrations and to put it into a very scalable architecture.

[00:54:10] Mike: Yeah, that's great. It's I think the kind of thing that, that is very encouraging too, to show developers like the, the price to try is free. And therefore, you know, theoretically the value proposition should be clear from there, right? Like, if, if the product speaks for itself, then it's easy to get started free and, and kind of dive in.

[00:54:25] Roy: And I think pricing model is really interesting that we didn't really talk about, you know, we talked about APIs and technical stuff, which I don't think we did enough of, but I think pricing is so important because you want this to work with your pricing model. If you're charging your customer 20 bucks, you don't want to pay 20 bucks a month for something like this.

[00:54:45] So we, within startup operators for a very long time, that was something that we thought about. Really hard. We actually took a lot of time in coming up with a pricing model that would work, that we would pay for, and we're like cheap. [00:55:00] You know, typically you know, AWS costs shouldn't be, you know, a hundred percent of our profit in margin.

[00:55:06] I, I think that is something that I, I'm quite proud of other than all the other a d I integrations that and all the API technology that we've put in there, you know, not only the rest a p I server, but the G R P C one, the GraphQL one in there also, that all of that tech that we built is, is really interesting.

[00:55:23] But the, I think the pricing model is key.

[00:55:26] Mike: Yeah, there's a lot of rabbit holes that I think we could poke our way into and maybe good reason to have you come chat with us again sometime soon. Roy where's the best place to find you online?

[00:55:34] Roy: So Roy Unified to is my email address reach out to me. You know, I'm on LinkedIn I'm on Twitter. Of course, you can find my coordinates pretty easily. And yeah, I I am very out here in the Toronto tech scene. Love to talk to, to other tech entrepreneurs. Obviously very passionate about APIs, but I'm also [00:56:00] very passionate about the tech ecosystem anywhere and tech entrepreneurs as well.

[00:56:05] Mike: Fantastic. And the final question I usually ask before wrapping is are you hiring? And if so what sorts of folks are you looking for?

[00:56:12] Roy: Yeah, we are hiring. So yeah, we are, we're five months old. We are raising halfway through raising our pre-seed round right now, our first round of financing. And we're four people right now. We're hiring a fifth. We're hiring a we're calling a customer success manager. Basically post sales, a p I.

[00:56:32] Technical but not coder list. Loves to work with customers. Get them to implement our E G I and technology.

[00:56:40] Mike: Got it. Oh, that's fantastic. Well, if that sounds like you and you're listening to this we will make sure that Roy's contact information is all over the show notes, just as well as show notes sorry, just as well as links to get to Unified as well as the promo code to get three months of free access with their startup plan.

[00:56:54] So make sure you check the show notes to grab those. Roy, it's been fantastic having you chat [00:57:00] with us and hang out. Would love to have you back and, and talk about where things are in six months, three months, a year, whatever it may be. And kinda see how things are going for you. Thanks so much for your time.

[00:57:08] I really appreciate having you here.

[00:57:09] Roy: Hey, thanks guys.

[00:57:10] Mike: All right. Take care.

[00:57:10] Phill: Yeah. Cheers everyone.[00:58:00]