The Data Stack Show - 43: Modern Authentication and User Management with Sokratis Vidros of Clerk.dev

Episode Date: July 7, 2021

Highlights from this week's episode:Sokratis' realization that big corporations were not the best thing for him (2:56)Transitioning for Workable to Clerk.dev (3:40)Convincing developers to outsource components to a service (9:36)Clerk's layered solutions and how it affects the developer and the end-user (12:41)Starting with Clerk from scratch vs. using Clerk to replace an existing component (19:55)Synergies and SaaS starter kit (24:06)Building Clerk to avoid a single point of failure (29:19)Reflecting back on the transformation and growth of Workable, and how it was like working at eight different companies (33:03)Lessons that Sokratis has taken away from his years as a developer (42:18)The Data Stack Show is a weekly podcast powered by RudderStack. Each week we’ll talk to data engineers, analysts, and data scientists about their experience around building and maintaining data infrastructure, delivering data and data products, and driving better outcomes across their businesses with data.RudderStack helps businesses make the most out of their customer data while ensuring data privacy and security. To learn more about RudderStack visit rudderstack.com.

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. Welcome back to the show. Today, we are talking with Socrates 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 has 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, but 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 Socrates about that. How about you, Kostas?

What's on your mind? Yeah, absolutely. I mean, okay, Socrates for me is a kind of special guest, to be honest, because I also know him personally and it happens also to be from Greece and he runs like an engineering team there. So I'm always happy to chat with him. Yeah, the product is a very interesting case of a product

because it solves like a problem that at the same time is causing a lot of frustration to engineers. I mean, having to integrate with different authentication services, for example, and every time have to do a new integration and all these things. It's not the easiest thing to do 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. Great. Well, let's jump in and hear from Socrates. Let's do it. 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. Thanks for having me.

Welcome everyone. So how would you like me to start? Would you like me to give you a brief presentation of my CV so far, my experience in the startup world? 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. Great. So basically my story starts around 2011 when I graduated from the National Technical University of Athens, Greece. Right after I moved to France, I spent around 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 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. My bank account was happy, but my job was not very creative. It's good to learn that early on in your career though. That's a good lesson to learn. Yes, definitely. So right after that, I decided to come back to Greece. It was during some very difficult years 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 in 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, sorry, it was in January 2013. Workable right now is a very big company, one of the leading vendors in terms of HR solutions. I was working at Workable

for around seven and a half years. When I left, I was a D of engineering. And for the past eight months, I've been working with a new team. The new project is called Clerc.dev, and we're in the user management space. So Clerc is a relatively new project, so I guess I have to say a couple of things about it. So basically with Clerc, what you can do is you can add beautiful sign-in and sign-up forms to your React application in minutes. We are trying to empower developers with reusable components and a very intuitive API in order to build the authentication 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've built authentication more than five to 10 times so far. And every time I think people wonder, I mean, 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. 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 scaled 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? Actually, it was both. In Workable, we're 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 realized 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 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. On top of that, you usually have to build another service that's gonna accompany the vendor for your customization. So I had this experience during my last two years in Workable. And then when I received 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 Clerc, and then it seemed that

all of us have faced the same experience with authentication so far. The story is similar to, let's say, billing. Billing used to be the same, and then Stripe came in, and Chalmersby, and all these checkout.com, and all these great services. And right now, billing is not so scary anymore. However, authentication used to be easy enough so as not to require the 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, SMSs, biometrics, et cetera. So if a developer wants to integrate all of this stuff in their application, that tends to be really complicated and time consuming. 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, 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. And so 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 sort of really, really core. And I'm just interested to know, what's the experience been like talking to developers about sort of 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? Or I'd just love to know what that experience has been like. Okay, that's actually a great 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,

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 their 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 their 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 we imagine, that's how we would like to

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 belong to the users. And 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 that we focus more on front-end developers and what's called the new jump-stack architecture. So it's basically a way to have very smart back-ends 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 these 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 I would like to hop on the same train and try to push forward that architecture. Because, I mean, we all know that most of the functionality across web applications, regardless if the application is a B2B or a B2C, is the same. So, for example, I would like people to think, okay, we're going to use Clerk for user authentication.

We're going to use Stripe for billing. We're going to use Algolia for user search, for data search. We're going to use Vc for user authentication, we're going to use Stripe for billing, we're going to use Algolia for user search, for data search, we're going to use Vercel for deployment, etc. Sokrati, you gave us a very good description of what the problem is and how you also decided to engage in this problem and its solution. Can you describe to us and give us a bit of a journey, let's say, on how Clerks is solving the problem and how this affects the developer who has to implement 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 it. So basically, in Clerks, we would like to say that we have a layered

solution. So it all starts from the front of the API. The front of the API is an API we provide to our customers for authentication. So it contains all the authentication-related methods you can imagine. And this front of the 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 customizations yet. We're planning to do it, but that's part of our roadmap. Then on top of that,

we also provide another abstraction that's basically, we're trying to port the vanilla JES, Clerc SDK, to every popular front-end framework. Right now, we're working with React, but we're also planning to do Angular, Svelte, components, and I don't know, any other popular library that our users will request. 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 Clerics is to be able to provide an optimized solution for every layer. So on top of that, our UO 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's been a lot of work in the background in order to make them as as performant as possible. The customers of our

customers would basically experience this beautiful high conversion and secure sign-in and sign-up process. So I think that 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 talking 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 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 correct correct 95 percent of the time yeah so i think the value there is pretty straightforward. I mean, the developer will get your SDKs, your templates,

and get out of the box solutions to provide authentication and also optimized authentication, right? Like something that can also affect the funnel, which is also important. How does this affect the backend developer, if it does at all? How is the rest of the stack, actually? Probably that's the best way to ask the question. How is the rest of the stack affected by a solution like Clerc?

We're trying to minimize the impact of Clerc for the backend developer, but of course, we can't eliminate it. So Clerc also handles session management. And by session management, the easiest way to describe it is basically Clerc finds a way to find a secure way to add a cookie to your backend API.

So this is basically the session cookie. This 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 backend 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 in a nutshell,

the backend developer needs to install one of our backend SDKs depending on the language they're using. And then the SDK will basically populate a field in the request. So you got to receive the request along with the user data. Right. This is great. And what part of, let's say, the concerns that the backend developer had in the past

are now offloaded to you, to Clerks? And I think another way to put that is there's always some kind of data model that lives on our own production database, right? And like there's always like a user table there. I mean, there's somewhere where we have like to populate user-related information. And of course, this user-related information also is related with authentication. It's one of the first things that everyone implements when we are building like a web

application at least. Now with Qlerk in between, what kind of information is shared between Qlerk and the application? And how does this work in two cases? Actually, the first case is like, let's say I start from scratch, right? So I'm starting today like to build an application and I started working using Qlerk from day one. And how do I migrate to using Clerk? Okay, good. So basically, the amount of information that Clerk serves 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? 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 like trying to do authentication. I want to start working with clerks. But I already have something there in place, right? So what's the difference in the experience there and how you do it in one case and the other? Okay, good. So starting from scratch with clerk is the happy part. It's 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 Clerc, actually, 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. Regarding the customers who reach out to us and they have already an authentication mechanism in place, they want to migrate, we still don't have a recipe yet. We're working with them to apply ad hoc solutions so far and trying to bug them for other technology. I don't want to say their names, their 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. So during a migration, from what you've seen so far, what's the hardest part of doing a migration

that is related to authentication? The hardest part is that you have to... I mean, you can't just do an ETL, basically export data from the first provider and import them to the second provider and try to synchronize things. The hardest part is that you have to do a live migration. You always have to do a live migration.

So imagine you're using a provider A. Your users interact with your website normally. They should migrate to the provider, 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 request in the second provider and then upset all the user data between those providers. That's why I'm saying you always have to do a live migration. And that's a very hard problem to solve. Yeah, 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, Chatsby 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 and as a payment processor, you can, again, have Stripe there, right?

But even in this case, moving from one subscription service to the other, it's a major pain. It's not easy to do. And it's both, as you said, it's both the service itself, in the sense of what endpoints 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, these two services don't have the exact same data model. And they have to be aligned somehow. And there's 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 these companies, it's great, right? Because this situation provides a lot of stickiness. But for the user, probably it's not that ideal, especially if you need to to do if you need to do this migration anyway my i can't tell you but like ask you what's the similarity between the authentication service as you describe it and which is the user management let's say and the subscription management that this service is offered like Stripe and Chargebee. And are there any synergies there?

Do you see Clerk benefiting when a company is using something like this or not? Because at the end, both services have to do with the user itself. Subscriptions also require it's around the user itself, right? So there is data there. So what are the differences? And do you see any opportunity there for Clerc to work with these services? Actually we do. Of course the problem is similar and the user management is similar to Beelink in a sense that these are cross-cutting concerns that we can find in almost every software,

especially every cloud software. So there's 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 have wanted to store credit cards in my Postgres or my SQL. So right now, I feel kind of relieved that Stripe takes good care of my data.

Actually, not my data, my customers' billing data. Yep. 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, hashing, secure storage, encryption at rest, encryption in transit, 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 these solutions. And we actually started some integrations. They are all in progress right now. In Stripe, the way I imagine 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 imagine 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 This is great I'm really looking forward to it and see how it can work. And I'm very also 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 Clerc? What's the biggest concern that your users have so far? So until now, the biggest obstacle, since it's a new project, has been feature parity. There are a lot of great products in the market, in our app 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 Clerc, especially on the front end, you are actually wrapping your whole application with what we call the Clerc provider.

The provider actually is the top-level state management solution of Clerc 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 Clerc. Otherwise, developers will get frustrated. For example, if we have excessive re-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 we'll continue working on the same projects

for, I don't want to say forever, but for the foreseeable future. It's funny because we have an internal, one of our internal teams is called the DX team. And its main focus is just that, trying to make Clerc as subtle and as performant as possible so that it doesn't mess with the host application. That makes total sense. And I think this is something that we can also relate that rather stuck, 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 like a dedicated probably episode at some point to discuss about like all the different tricks that can be done and all the different issues that can someone encounter while trying like to optimize this SDK. I think it's a very fascinating topic. So I have a question because you were saying about your services and deadpoints. How important it is? Let's say I'm a user of Clerk, right?

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? 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 networkless authentication or offline authentication.

And this is a technology and strategy that has been around for many years. And this is something that and strategy that has been around for many years. And this is something that other vendors do as well. And this is going to make your application prone to failures in Qlerk. We're trying to have the best SLA, but we all know that at some point in time, Qlerk will fail, like every other system. So we would like to have, we'd we would like your applications to continue working, at least for existing users,

sorry, at least for already 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. This is very fascinating. So how does this offline authentication, I don't remember exactly how you named it, works?

That's super interesting. What's the main basic principles behind it? So the basic principle is that we rely a lot on short-lived tokens. And by short-lived, usually these tokens last for around a couple of minutes. And the idea is that you trust these tokens by using some asymmetric cryptography. And you can validate them on your backend without having to do a request to the Clerc backend API. And that makes your application functional for that interval. to do a request to the Clerc bucket API. It enables you to... And that makes your application functional

for that interval. So there's also a technology called WKS. So it's basically a way to distribute all the keys you're using in order to sign those JWTs. And then there's your bucket. The backend of your application knows how to verify these sort of tokens by itself periodically of course it has to query it has made a request to declare back end 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 a request. Wow, you are working with some very fascinating problems, I have to say. I'm a little bit jealous. So I'd love to hear more about it. So maybe we can... No, maybe. i'm definitely going to ask you more stuff offline because okay we have to also ask like some other questions and i i want to ask you something a bit more personal socratic you mentioned at the beginning that you started in your previous company workable as like 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 the company perspective, right? Because a company with just two engineers to a company that is like the leader in one of the leaders in its space. We are talking about like way too much transformation happening in the company, right? Like we are talking about probably like two completely different companies if you compare them. So how was this journey for you and for the company? Can you give us a little bit more information about that? Yes, actually, that was an amazing journey

and I was really lucky to be part of the Workable team early on. It's not just two different companies. It's been more than eight different companies in the past eight years. So it was like we were entering a different era every like eight months. The growth was remarkable. And 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's why I consider myself lucky to be part of that team. During the early days, we were 100% hands-on. We had to build everything. Every team. During the early days, we were 100% hands-on, we had to build everything, every single detail affected the outcome, the business outcome, the 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 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're always saying, yeah, let's, 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. 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 become the vp of

engineering and now you're let's say back to being like a founding engineer right What made you do that? How did you decide to go from being an individual contributor to a leadership role and back to being an individual contributor again? Why did you do that? Honestly, I missed being an individual contributor. I always liked having a balance between being an individual contributor and being in a more managerial role. Luckily enough, I was never 100% in the managerial role because I have to be honest with you, I don't like that very much. But I missed having to do 90% of my work in VS Code all day. So that was one of the key reasons I wanted to join a project like LERC 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 performance teams. And LERC is a project that can offer the balance that I'm looking for at this point. Oh, this is great. And one last question from 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 on this VP leadership role

now that you're back as an individual contributor? 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 chilled. And this 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 chilled.

And this is not something, this is not a luxury you can enjoy in an early stage startup like Clerc. 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. But I was saying, okay,

I wish I was working in a more relaxed environment. Yeah, yeah, I get it. Makes total sense. Eric, the stage is yours. Well, thank you. We're getting close to time. But I do have, 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 I 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, of 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'd just be 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? Actually, the product that we use, the main outlet that we use, is our APIs. And we obsess over every detail 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 the 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 going to 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 main, the primary storage for user data. We had a couple of requests from companies who handle extremely sensitive user data, medical data, et cetera.

So I guess these people have very good reason to keep their 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. Do you think that that is an architecture that we'll see in the future? The terminology that Costas and I use is, we kind of say that's warehouse first, right?

Where a company brings their own data store and platforms will enable sort of apps to run on their own data store. I mean, it's an interesting, we see that more and more really across the spectrum. I mean, it's interesting to hear Clark thinking about that. RutterSec 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?

Yes, definitely. And I'm happy to see new technologies emerging that they have new, they have interesting, they have some new interesting pictures. For example, I was checking the database that allows you to store data to specify basically the geographic 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. Yeah, it's going to be such an interesting five years i mean the the database the database vendors and i mean we've talked with people building on snowflake

we've talked with people building uh 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 at Clerk and that sort of have shaped the way that you approach building software? 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

number, that's the top priority for me. If you manage to do that successfully, then every day you're going to 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. I think that's a great lesson and really 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 is just a valuable lesson to always keep in the back of our minds as we work in the tech industry. Well, so Kratis, this has been really, really a great conversation. Costas 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. Great, I'd be happy to answer any questions.

Cool. Well, thanks for joining us. Best of luck with Clerk and clerk.dev, I believe is the URL, if anyone in the audience wants to check it out. Thanks for joining us. Thanks for having me. A 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. Absolutely. It's very fascinating what they are trying to do, both from a technical and a business perspective. And hopefully in a couple of months, we will have him back and learn more about their journey. He shared a lot of technical details about what they are 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 like 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 all the stuff that he shared around that

were extremely, extremely fascinating and interesting. For sure. Thanks for joining us again on The Data Stack Show, and we'll catch you next time. 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, ericdodds, at eric at datastackshow.com.

That's E-R-I-C at datastackshow.com. The show is brought to you by Rutterstack, the CDP for developers. Learn how to build a CDP on your data warehouse at rudderstack.com.