Modern Authentication and User Management with Sokratis Vidros of Clerk.dev

Eric Dodds  00:06

Welcome to The Data Stack Show. Each week we explore the world of data by talking to the people shaping its future. You’ll learn about new data technology and trends and how data teams and processes are run at top companies. The Data Stack Show is brought to you by RudderStack, the CDP for developers. You can learn more at RudderStack.com.

Eric Dodds  00:28

Welcome back to the show. Today, we are talking with Sokratis from Clerk. And Clerk is a really interesting tool. They’re providing authentication and user management as a service for software developers. So there’s a lot to talk about there. He was also at Workable very early. Workable’s become a huge company in the HR space. And I think my burning question, when you think about user management, it’s a very … maybe sensitive is not the right word, but it’s really core to software development and it’s really core to data, right? Your users are sort of the most central part of your app in developing software. And because of that dynamic, it’s interesting to think about a company that’s trying to get their customers to let them manage one of the most important pieces of the puzzle, as far as data goes. So I cannot wait to ask Sokratis about that. How about you Kostas? What’s on your mind?

Kostas Pardalis  01:26

Yeah, absolutely. I mean, okay, Sokratis for me is a kind of special guest, to be honest, because I also know him personally, and he also happens to be from Greece. And he runs an engineering team there, so I’m always happy to chat with him.

Kostas Pardalis  01:40

Yeah, the product is a very interesting case because it sounds like a problem that at the same time is causing a lot of frustration to engineers. I mean, having to integrate with different application services, for example, and every time having to do something like a new integration and all these things, and there’s always security implications there. But at the same time, it’s something that it’s not the easiest thing for a company to decide to adopt. So I want to hear from him what kind of unique challenges they have both from a technical standpoint, but also in terms of go to market and actually building a business around this kind of problem.

Eric Dodds  02:21

Great. Well, let’s jump in and hear from Sokratis.

Kostas Pardalis  02:25

Let’s do it.

Eric Dodds  02:27

Welcome to the show. We’re really excited to chat with you about stuff you’ve learned over the years, and then your current project, Clerk. Thanks for joining us.

Sokratis Vidros  02:36

Thanks for having me. Welcome, everyone. So how would you like me to start? Would you like me to maybe give you a brief presentation of my CV so far, my experience in the startup world?

Eric Dodds  02:47

Yes, I would love that. We love hearing people’s stories. And that’s usually where we start. So take it away. We’d love to hear about your background and kind of what led you to where you are today.

Sokratis Vidros  02:56

Right. So basically, my story starts around 2011 when I graduated from the National Technical University of Athens, Greece. Right after that I moved to France, I spent about a year in Nice, in Côte d’Azur. It was one of the best years of my life so far. I did my master’s there. So right after that I started working in Paris, in SAP. That was a great experience for me, but it also made me realize that these big corporations are not the best thing for me.

Eric Dodds  03:35

It’s good to learn that early on in your career, though. That’s a good lesson to learn.

Sokratis Vidros  03:40

Yes, definitely. So right after that, I decided to come back to Greece, because it was during a very difficult year for the Greek market, because we were in the middle of the Greek crisis, the Greek financial crisis, actually. But I decided to come back to Greece to start working at Workable. Workable back then, was a very small startup. I was the second engineer to join the team. Back then there were just five people. That was in December, actually, no, so it was in January 2015. Workable right now is a very big company, one of the leading vendors in terms of HR solutions. I worked in Workable for around seven and a half years. When I left, I was the VP of Engineering.

Sokratis Vidros  04:29

And for the past eight months, I’ve been working with a new team. The new project is called Clerk.dev and we’re in the user management space. Clerk is a relatively new project, so I guess I have to say a couple of things about it. So basically, with Clerk you can add beautiful signin and signup forms to your react application in minutes. We’re trying to empower developers with reusable components and a very intuitive API, in order to build our application process as fast as possible, and move on with actual core features of their products. So I’m sure all of you have built software in the past, I’m sure that you will have iterated more than five to 10 times so far. And every time, I think people wonder, there must be a faster way to do that. Of course, there’s a lot of competition, but we focus primarily on developer experience. And I think that’s what’s really special about this project so far.

Eric Dodds  05:35

I’d love to hear about … I have a lot of questions about seeing the journey at Workable, especially around sort of the stack and how things scale since you were the second engineer there … but I’d love to know what led you to starting Clerk. Was it personal experiences of trying to build authentication over and over? Was it dissatisfaction with other tools? I’d just love to know where the idea started and why you decided to leave a really successful company to start Clerk?

Sokratis Vidros  06:06

Actually it was both. In Workable we were facing similar problems, especially when we decided to switch to a microservice architecture. So we’ve started building again, and again, authentication for different services, and then the experience at the end of the day wasn’t optimal, because overall the UX was broken. We tried to use existing solutions,  but we realize that the promise, when you visit the marketing side of an existing solution, is always this is an off the shelf product, just install it, and get up and running in 30 minutes. Actually, that’s only true for the demo cases. And then in reality, what happens is that every project like that then turns out to be a huge integration project that requires at least two to three months. And then you have to constantly maintain it.

Sokratis Vidros  06:58

On top of that, you usually have to build another service that’s going to accompany the vendor for your customization. So I had this experience during my last two years in Workable. And then when I saw an email on LinkedIn for this new project, I was like, Okay, that makes a lot of sense. So I talked to my partners, the co-founders of Clerk and then it seemed that all of us had faced the same experience with authentication so far. The story is similar to let’s say, billing. Billing, we used to be the same, and then Stripe came in and Chargebee, and all these great services, and right now billing is not so scary anymore.

Sokratis Vidros  07:47

However, authentication used to be easy enough, so as not to require a dedicated service. But right now, we are all very spoiled when it comes to authentication and user data, because we all expect Google and Facebook quality of user management. So that includes second factor authentication, SMS, biometrics, etc. So if a developer wants to integrate all of this stuff into their application, that tends to be really complicated and time consuming.

Eric Dodds  08:20

Sure. Well, I know Kostas has a bunch of questions. But one question for me, that’s really interesting, and I think the Stripe example is a really good one. I think sometimes in the early phases, when you think about sort of a component of software development, being turned into a service, like billing, a lot of times, there’s sort of a, of course, you have early adopters, but there can sometimes be a mindset of I don’t necessarily want to outsource this part of my app, right? If you think about billing, it’s a really important component, you want to maintain a high level of control. Obviously, Stripe is immensely successful, but it took a lot of work for them to build trust among developers to take over their billing. And it’s interesting with Clerk because user information, that’s sort of the logging in, creating an account, authentication, all that sort of stuff is really, really core. And I’m just interested to know, what’s the experience been like, talking to developers about outsourcing that to a service, as opposed to doing it themselves? Does there seem to be a lot of desire for them to own that? I just would love to know what that experience has been like?

Sokratis Vidros  09:36

Okay, that’s actually a good question. Because, indeed, it’s really hard. And I guess, actually, I’m sure it must have been really hard for Stripe as well. I think an example that we usually use in order to try to not convince people and to explain to people what we’re trying to do is basically the example of Dropbox and all these file hosting services. So before Dropbox and Box and all the enterprise file hosting solutions, companies had all the data in their own hardware on premise. At some point, the cloud revolution happened and then storing data on the cloud was way cheaper. So it must have been a really great effort to convince Airbus or Boeing to store the designs of very new and brand new airplanes on the cloud. However, I think, I mean, I don’t know if they do it, but I’m sure they store stuff on the cloud right now. So that’s how I think user data will behave in the future. Of course, it’s hard. People are reluctant to do it. Of course, we’re just providing the infrastructure, the data belongs to the user. And then they have all the tools they need in order to access them anytime and in any way. So we’re just providing an infrastructure for them. Also, the way we structure our solution, we would like to focus more on front end developers and what’s called the new jumpstart architecture. So it’s basically a way to have very smart backends in order to be able to do as much as possible and have as much functionality as possible on the front end with the minimum effort. So, people that build their application that way, embrace our effort so far, it’s just that this thing is relatively new. So that’s why we’d like to hop on the same train and try to push forward that architecture. Because we all know that most of the functionality across web applications, regardless if the applications are b2b or b2c, is the same. So for example, I would like people to think okay, well, I’m going to use Clerk for user authentication, I’m going to use Stripe for billing, use Algolia for data search, etc.

Kostas Pardalis  12:10

Sokratis, you give us a very good description of what the problem is, and how you also decided to engage in this problem and the solution. Can you describe to us and like, give us like a bit of a journey, let’s say, on how Clerk is solving the problem, and how this affects the developer who has implemented it, of course, and also the end user at the end, right? Because it’s something that the end user also one way or another is going to interact with.

Sokratis Vidros  12:41

So basically, at Clerk, we would like to say that we have a layered solution. So it all starts from the front-end API. The front API is an API we provide to our customers for authentication. So it contains all the authentication related methods you can imagine. And this API contains first factor authentication, second factor authentication. It can give you a way to track your sessions, to track your devices, manage your user data, etc. On top of that, we offer a browser SDK. So this is an abstraction layer. This is if you want to have some utilities, and complete your tasks faster. On top of the SDK, we offer another layer that’s basically pre-built opinionated user management components. These components are, of course, customizable, but the reason I’m saying opinionated is because they’re customizable to some extent. We can apply theming, but we don’t apply layout customization customizations yet. We’re planning to do it, but it’s part of our roadmap. Then on top of that, we also provide another abstraction, that’s basically we’re trying to port the VanillaJS clerk SDK to every popular Front End framework. Right now we’re working with React, but we’re also planning to do Angular as well. And I don’t know, any other popular library that our users will request.

Sokratis Vidros  14:12

So if we imagine the solution as a layered cake, if we go towards the top of the cake, we get velocity as developers, we go towards the bottom, we get more customization. So the idea for Clerk is to be able to provide an optimized solution for every layer. So on top of that, our components, we’re trying to work hard on them, and we’re trying to achieve high conversion rates. So our customers would also benefit from that. These are not just random UI components that we design. There has been a lot of work in the background in order to make them as performant as possible. The customers of our customers will basically experience these beautiful high conversion and secure sign in and sign up processes. So I think the benefit for them is basically, if our customers were using their own solutions, they would have to build their own thing, and they would need to spend more time. Usually what developers do is that they always evaluate the trade offs. And sometimes we cut corners. So I guess that the authentication, we might also cut corners on authentication. I’m not thinking about security, but we might also cut corners on features about authentication. So I guess the advantage with Clerk is that you don’t have to lose any features that other competitors might have. You can just get them from Clerk.

Kostas Pardalis  15:50

That’s super interesting. So from what I understand, and correct me if I’m wrong, like the first developer who interacts with the solutions Clerk provides is the front end developer, right? Is this correct?

Sokratis Vidros  16:00

Correct. Correct. 95% of the time.

Kostas Pardalis  16:03

Yeah. So I think the value there is pretty straightforward. I mean, the developer will get your SDKs, like your templates, and get an out of the box solution to provide authentication and also optimize authentication, like something that can also affect the funnel, which is also important. How does this affect the back end developer? If it does at all, like, how is the rest of the stack? Actually, that’s the best way to ask the question: how’s the rest of the stack affected by a solution like Clerk?

Sokratis Vidros  16:37

We’re trying to minimize the impact of Clerk for the back end developer, but of course, we can’t eliminate it. So Clerk also handles session management. And by session management, the easiest way to describe it is basically Clerk finds a secure way to add a cookie to your back end API. So this is basically the session cookie. The session cookie is the only thing that the backend developer needs in order to set the user context. So this is basically the minimum thing that the back end developer has to do, in order to verify that the request is authenticated, accept the user, and then proceed with the actual business logic. So the in and out sell, the back end developer needs to install  one of our back end SDKs, depending on the language they’re using. And then the SDK will basically populate the field in requests. So you can receive the request along with the user data.

Kostas Pardalis  17:46

Right, this is great. And what part of let’s say the concerns that the back end developer had in the past are now offloaded to you, to Clerk. And I think another way to put that is, there’s always like, some kind of data model that lives on our production database, right. And like, there’s always like a user table there. I mean, there’s somewhere where we have to populate user related information. And of course, this user related information also is related to authentication. It’s one of the first things that everyone implements when we’re building a web application at least. Now with Clerk in between, what kind of information is shared between Clerk and the application? And how does this work? In two cases, actually, the first case is like let’s say I start from scratch. So I’m starting today to build an application, and I started using Clerk from day one. And how do I migrate to using Clerk?

Sokratis Vidros  18:47

So basically, the amount of information that Clerk shares with the customer’s application is basically all the user data. So this really depends on the implementation itself. By default, if you don’t need to have any user data in your application, you just need the user ID. That’s enough to set the context for the business logic. That’s after the authentication step. So this is the minimum setup. So what was the second part of your question?

Kostas Pardalis  19:19

The second part of the question is how do you use Clerk in two different cases? Right. One is when you start from day one to use Clerk, and how’s the experience there? So the question is actually more focused on the developer experience. And, second, when I already have built something, right, and I decided, okay, I had enough of trying to do authentication, I want to start working with Clerk. But I already have something in place, right. So what’s the difference in the experience there and how do you do it in one case to the other?

Sokratis Vidros  19:54

Okay, good. So starting from scratch with Clerk is the easiest thing to do. Right now we focus a lot on developer experience and that’s the main flow we have optimized so far. So every single click counts, and in Clerk we have a YouTube video demonstrating our product, you can have an application template up and running in around three minutes with authentication, and then you can start from there. So this is very easy. And this is the most optimized flow at the moment.

Sokratis Vidros  20:31

Regarding the customers who reach out to us and they have another application in place already, and they want to migrate, we still don’t have a recipe yet. We’re working with them. Basically we’re working with them to apply ad hoc solutions so far, and trying to migrate and debug them for other technology, I don’t want to say, right now, the names or brand names, but we’re trying to figure out based on the use case, how are we going to migrate them in a way that the users won’t be disrupted.

Kostas Pardalis  21:03

So during a migration, from what you’ve seen so far, what’s like the hardest part of doing a migration that is related to authentication?

Sokratis Vidros  21:14

The hardest part is that you can’t just do an ETL, basically export data from the first provider and import them to the second provider, drag to synchronize things. The hardest part is that you have to do a live migration. And you always have to do a live migration. So imagine you’re using provider A, your users interact with your website, normally. They should migrate to the second provider, in a seamless way. So from a high level point of view, you have to replicate every request. So if I sign in, and I provide my username and my password, what I need to do at this point is to execute the request in the first provider, and then try to replicate the same request in the second provider, and then send all the user data between those providers. That’s why I’m saying you almost have to do a live migration. And that’s a very hard problem to solve.

Kostas Pardalis  22:11

Yeah, it makes sense. It reminds me a little bit to be honest of trying to migrate from a subscription service to another subscription service. I had this experience with using, for example, Chargebee, to manage your subscriptions. And then you want to move to Stripe for the subscriptions. Where, by the way, you can use, for example, Chargebee, as a payment processor, you can, again, have Stripe there, right? But even in this case, like moving from one subscription service to the other. It’s a major pain, like, it’s not easy to do. And it’s both, as you said, like it’s both the service itself, like in the sense of like, what in points you have to go and call and all that stuff, which is on the API level, let’s say. But it’s also the data model. Because of course, like these two services, they don’t have the exact same data model, right? Like, they have to be aligned somehow. And there is a lot of logic on the application itself that relies on these subscription models that have been implemented there. And it’s a very interesting problem, actually, of course, for this company, this is great, right? Because this situation provides a lot of stickiness. But for the user it is not that ideal, especially if you need to do this migration.

Kostas Pardalis  23:27

Anyway, what’s the similarity between the authentication service as you describe it, which is user management, and the subscription management that these services offer, like Stripe and Chargebee? And are there any synergies there?

Kostas Pardalis  23:46

Do you see Clerk benefiting when the company is using something like this or not? Because at the end, both services have to do with the user itself, like subscriptions also require it around the user itself, right. So there is data there. So what are the differences? And do you see any opportunity there for Clerk to work with these services?

Sokratis Vidros  24:06

Actually, we do. Of course, the problem is similar. And user management is similar to billing, in a sense that these are cross cutting concerns that we can find in almost every software, especially cloud software. So there are a lot of things in common. There’s tons of security concerns. And actually, this is one of the benefits of using solutions like Stripe for billing or Clerk for authentication. Personally, I would never want to store credit cards in my Postgres or in my mySQL. So right now I feel kind of relieved that Stripe takes good care of my data, actually, not my data, my customers billing data.

Sokratis Vidros  24:52

I guess that’s what we want to achieve with user passwords, one time codes, etc. with Clerk. It’s hard to store them in a secure way. And as a developer, you would like to offload that and delegate to a dedicated service so that you don’t have to worry about salting, caching, secure storage, encryption at rest, encryption in transit, etc, etc. Regarding synergies, we are actually trying to … I mean, one of the goals we have for the future is basically to create what we call the SaaS startup kit. So, this kit would basically include authentication, billing, analytics, some communication templates, etc. So we would really like to integrate with all the solutions. And then we actually started with some integrations that are all in progress right now. In Stripe, the way I imagined is that, first you have the user, and then you have everything else. So as soon as you have the user, then you can integrate with almost every service. After the user usually comes the billing, and all the payment gateway logic. So the way we imagined is that, yes, pretty soon we will have correct Stripe integration, and we would like to offer that as part of our SaaS starter kit.

Kostas Pardalis  26:20

This is great. I’m really looking forward to it and seeing how it can work. And I’m very interested in this stack, the SaaS stack that you’re talking about. That’s also going to be awesome. So what’s the biggest obstacle that you see so far, when it comes to the adoption of Clerk? Like what’s the biggest concern that users have, your users have, so far?

Sokratis Vidros  26:43

So one of the biggest obstacles, since it’s a new project, has been feature parity. There are a lot of great products in the market that have been around for years. So it’s normal that they offer more features than we do, but we’ve been working hard for the past eight months. So this is not the biggest issue anymore. The biggest obstacle we’re facing, and I think we’re doing great work, but still one of the biggest pain points, is that by using Clerk, especially on the front end, you are actually wrapping your whole application with what we call the cloud provider. Provide actually is the top level state management solution of Clerk for react. So if you have to do that, you have to be really performant. We don’t want to put a burden on our customers’ applications, just by using Clerk. Otherwise, the developer will get frustrated, for example, if you have excessive renders, or if our provider is slow or if our API endpoints are slow. People won’t like that. So that’s one of the trickiest things to do out there. And that’s basically one of the main projects we’ve been working on for the past three or four months and will continue working on the same project for, I won’t say forever, but for the foreseeable future. It’s funny because we have one of our internal teams called the DX team. And its main focus is just that, trying to make Clerk as subtle and as performant as possible. So that it doesn’t mess with the host application.

Kostas Pardalis  28:24

That makes total sense. And I think this is something that we can also relate to at RudderStack, to be honest, like anything that has to do with front end, web, and SDKs, performance is like one of the most important things. So we can totally relate to that. And it’s a very interesting topic. And I think we should have a dedicated episode at some point to discuss all the different tricks that can be done and all the different issues that someone encounters while trying to optimize these SDKs. I think it’s a very fascinating topic. So I have a question because you were talking about, like your services and endpoints, let’s say I’m a user of Clerk, right, like I have used your SDKs, I have integrated them on my web application. And I’m using your service and your service goes down, what happens?

Sokratis Vidros  29:19

So we’re trying to build Clerk in a way that it’s not going to be a single point of failure. So right now, a new project that will start in July, is focusing primarily on that. The idea is that we will introduce what we call network-less authentication, or offline authentication. And these are technologies that have been around for many years, and this is something other vendors do as well. And this is going to make your application prone to fair use in Clerk. We’re trying to have the best SLA but we all know that at some point in time, Clerk will fail, like every other system. So we would like to have your applications to continue working, at least for authenticated users, until Clerk is back online. In a distributed world, this will happen. For sure, we won’t be able to build Clerk in a way that this is going to be 100% bulletproof, but we are trying to do our best.

Kostas Pardalis  30:27

It’s very fascinating. So how does this offline dedication, don’t remember exactly how you named it, work? Like that’s super interesting. What’s the basic principles behind it?

Sokratis Vidros  30:40

So the basic principle is that we rely a lot on short-lived tokens. And by short-lived, usually these tokens last around a couple of minutes. And the idea is that you trust these tokens by using some as your method of cryptography. And you can validate them on your back end without having to do a request to the cloud backend API. And that makes your application functional for that interval. So there is also a technology called WKS. So there is basically a way to distribute all the keys you’re using in order to sign the JWDs. And then the backend of your application knows how to verify these tokens by itself. Periodically, of course it has to query when it has made a request to the cloud backend, in order to be able to get the new keys and get any other data that might have changed. But in a nutshell, your backend should be able to verify the tokens without the request.

Kostas Pardalis  31:52

Wow, you’re working on some very fascinating problems, I have to say. I’m a little bit jealous. And so I’d love to hear more about it. So, I’m definitely going to ask you more stuff offline, because we have to also ask some other questions. And I want to ask you something a bit more personal, Sokratis. You mentioned at the beginning that you started in your previous company Workable as the second engineer, and you stayed there for quite a few years, and you ended up being like the VP of Engineering there. Can you describe a little bit what’s the experience for a person to go through this journey? Because both on a personal level and also from, from the company perspective, right, because a company with just two engineers to a company that is like one of the leaders in the space, we are talking about way too much transformation happening in the company, right? Like, we are talking about probably like two completely different companies, if you compare them from then to now. So how was this journey for you and for the company? Can you give us a little bit more information about that?

Sokratis Vidros  33:03

Yes, actually, that was an amazing journey. And I was really lucky to be part of the Workable team early on. It wasn’t just two different companies. It’s been more than eight different companies in the past eight years. Yeah. So it was like, it was like, we were entering a different era every like, eight months. And the growth was remarkable. And in the end, every stage of the company was really interesting. Because I was exposed to new things. And I was always learning new things at double speed. So that was why I considered myself lucky to be part of that team. During the early days, we were 100% hands on, we had to build everything, every single detail affected the outcome, the business outcome, engineering outcome, so that was exciting. Then, as the company was getting bigger, we had bigger problems to solve. We had to solve performance issues. We had to solve user UX issues. We had to create a strong team, and we had to hire hundreds of engineers, and then make them effective in smaller teams. That was, again, another super interesting era. And then, at the end of the day, we had to solve every problem from the first day to the last day. I mean, it’s funny, because during the early days, we were always saying balance. Right now we’re doing everything. So in two years from now, the company is going to grow big, and then we’re going to hire other people to delegate more, but actually, that never happens, because you just have bigger problems.

Kostas Pardalis  34:41

Yeah, exactly. So I mean, you did this amazing journey, right? Like you went from being like an individual contributor, number two in the engineering team, to becoming the VP of engineering. And now you’re, let’s say back to being like a founding engineer, right? What made you do that? Like, how did you decide to go from being an individual contributor to like a leadership role and back to being like an individual contributor again, like, why did you do that?

Sokratis Vidros  35:17

Honestly, I missed being an individual contributor. I always liked, you know, having the balance between being an individual contributor and being in a more managerial role. Luckily, NATHA was never 100% of the managerial role. Because I have to be honest with you, I don’t like that very much. But I miss having to do 90% of my work in VSCode all day. So that was one of the key reasons I wanted to join a project like Clerk that was in its infancy. And it required a lot of coding. It still requires a lot of coding in order to get it off the ground. So yeah, I like writing code. I also like building performant teams. And Clerk is a project that can offer the balance that I’m looking for at this point.

Kostas Pardalis  36:11

Oh, this is great. And one last question for me. And then I’ll leave it to Eric, I’m sure he has a lot of questions to ask you. Is there something that you are missing from being like, on like a VP leadership role now that you’re back as an individual contributor?

Sokratis Vidros  36:31

I wasn’t prepared for this question. What am I missing? Actually, I think that if you work in an established company, even if this company is a startup, there are some days when you wake up and you say, I don’t want to work today. I want to be chill. And this is not a luxury you can enjoy in a early stage startup like Clerk. So there are some days, like yesterday, for example, that the temperature was very, very warm in Greece, and I would like to be by the beach.

Kostas Pardalis  37:04

Yeah, I get it. Makes total sense. Eric, the stage is yours.

Eric Dodds  37:13

Well, thank you. We’re getting close to time, but this has been a fun episode. Because I think it’s really fun to hear about the early stages of building software, especially building software that is directly involved with sort of core customer data. So it’s been a fun conversation. But one thing I was thinking about that I’d like to know, and we can maybe have one more question after this, but we can wind it down after this because I know we’ve been going for a while. But in building a service like Clerk, there are many, many components, obviously, what you do, the experience being one of the main ones, right, so you provide an experience for developers to make authentication and user management really easy. But one thing that’s interesting is that you also have to provide them with data. And I think about Stripe the same way, right, where they make billing really easy. But they also have to provide services to make the billing data available to you, because you’re not building it yourself. If you’re building it yourself, you basically have direct access to the app database, and you can get the data out of it for things like reporting and other things like that. And I am just interested to know how do you think about building that? Because it’s kind of a different problem providing your customers with data about the service that you’re providing them, along with providing the service? And how are you thinking about that and building that at Clerk?

Sokratis Vidros  38:46

Actually, the product that we use, the main output we use is our APIs. And we obsess over every data of our API definition and documentation, so that it’s extremely streamlined for our customers to get access to their data. I guess that’s I mean, in a distributed system, that’s the only thing you can do, because it’s hard for us to expose our database, especially since we’re a multi-tenant solution. And this is what we do now. In the future, we’re also thinking of an offering that’s gonna allow our customers to use their own database. But we will be providing all the user management, authentication, business logic, and then users will be able to store user data in their own storage. So that’s going to be basically the primary storage for user data. We had a couple of requests from companies who handle extremely sensitive user data, medical data, etc. So I guess these people have very good reasons to keep the data as close as possible to their software. So we had a couple of conversations in the past few weeks about a future offering that’s going to enable that as well.

Eric Dodds  40:06

Do you think that that is an architecture that we’ll see in the future? The terminology that Kostas and I use is that’s warehouse first, right? Where a company brings their own data store. And platforms will enable the apps to run on their own data store. I mean, it’s interesting, we see that more and more really, across the spectrum. I mean, it’s interesting to hear Clerk thinking about that, RudderStack is obviously structured that way. But there’s marketing tools and other things that are following the same architecture, which is interesting. Do you think we’ll see more of that in the future?

Sokratis Vidros  40:43

Yes, definitely. And happy to see new technologies emerging that have some new interesting feature sets. For example, I am checking a database that allows you to store data, to specify basically the geographical location of the data. So you can say, I want this column of this table to be stored in Germany, and this one in Asia and this one in Chicago. So I think that this problem will be mostly solved by database vendors. And then we will build SaaS accordingly.

Eric Dodds  41:21

Yeah, it’s gonna be such an interesting five years, I mean, the database, the database vendors, and I mean, we’ve talked with people building on Snowflake, we’ve talked with people building Graph. I mean, there’s all sorts of interesting stuff happening. And I think, as things get more advanced over the next five years, it’s going to be really interesting. Last question for you. And I’m thinking about our audience here. We always like to glean some lessons from people who have experience, and I know Kostas asked you about your personal experience at Workable, and now doing your own startup. But I’d love to know, what are some of the biggest lessons you learned, as an engineer building a product that needed to scale pretty significantly, as you think about seven or eight years at Workable? What are some of the biggest lessons you take away as a developer, that you’re using a Clerk and that sort of have shaped the way that you approach building software?

Sokratis Vidros  42:18

I think the most important thing is that you need to realize as soon as possible that building software is a collaborative effort. So you need to start working with the right people and build and hire the best talent for your project. So that’s the top priority for me. If you manage to do that successfully, then every day you’re gonna be working with a team that challenges you, that can solve any problem, and at the end of the day, you’re going to be happy about it. So that’s the key ingredient to the success of every company.

Eric Dodds  42:56

I think that’s a great lesson. Really it’s something that we’ve heard in many different contexts, as we’ve talked with people, from data scientists to data engineers, and the people behind the data and the software is a recurring theme, which I think it’s which I think is just a valuable lesson to always keep in the back of our minds as we work in the tech industry.

Eric Dodds  43:23

Well, Sokratis, this has been really a great conversation. Kostas is going to follow up with you offline, to get really nerdy on some of the problems you’re solving. And maybe we can convince you to come back on the show and talk about some of those things. Cool. Well, thanks for joining us. Best of luck with Clerk and Clerk.dev is the URL if anyone in the audience wants to check it out. Thanks for joining us.

Sokratis Vidros  43:51

Thanks for having me.

Eric Dodds  43:53

Super interesting conversation with Socrates. You know, my big takeaway was I loved the analogy of Stripe and transactional data, and how there are so many parallels between the level of sort of care and protection of that data as there is with user data. And I thought that was just a really good way of understanding some of the challenges and opportunities that Clerk has. So yeah, it’ll be really interesting to see where they go and what they accomplish.

Kostas Pardalis  44:23

Absolutely. It’s very fascinating what they are trying to do both from a technical and business perspective. And hopefully in a couple of months, we’ll have him back and learn more about the journey. He said a lot of technical details about what they’re building in their product. But what I found extremely fascinating, which is more of something a little bit more personal, is watching his journey, starting from being like the second engineer in Workable, reaching the level of becoming VP of engineering of a pretty big organization and actually going back to become the founding engineer of another startup. I think the experience and like all the stuff that he said around that was extremely fascinating, for sure.

Eric Dodds  45:15

Thanks for joining us again on The Data Stack Show and we’ll catch you next time.

Eric Dodds  45:21

We hope you enjoyed this episode of The Data Stack Show. Be sure to subscribe on your favorite podcast app to get notified about new episodes every week. We’d also love your feedback. You can email me, Eric Dodds, at Eric@datastackshow.com. The show is brought to you by RudderStack, the CDP for developers. Learn how to build a CDP on your data warehouse at RudderStack.com