Solving User Authentication with Julianna Lamb | Ep. 55

Speaker A: So much of it is solo, uh, which is like, so different than how you work. Software engineering, I think, is very much a team sport and you have people to bounce ideas off of and help you when you get stuck and things like that. And so I really enjoy the collaboration aspect.

Speaker B: Hey, friends. This is Podcast Rune by Software Engineer. On this episode, I get to talk to Julieta Lam, co founder and CTO of Stytch. Stytch is a user authentication platform providing solutions to manage all your user logins, as well as fraud detection. Best part, it's built by developers for developers. If you enjoy podcasts written by a software engineer, don't forget to hit the follow button on your podcast app, um, so you don't miss out on the new episodes and you can pick up podcast merch@parity.com shop. Enjoy the episode. Welcome back to another episode of Podcasting by Software Engineer. I'm your host, Perry, and today with me is Juliana Lam. I'm co founder and CTO of Stytch. Julian. How are you today?

Speaker A: I'm, um, good. Thanks so much for having me on. How are you?

Speaker B: I'm doing great, thank you. And obviously, like, I have to be on the thanking because not only is this podcast by one software engineer today, we're actually ruining it with two software engineers today. I always love, love, love when I get to, you know, we're gonna dive obviously into Stytch and also everything about, like, what it's solving today. But really, really briefly though, just to kick us off, who is Juliana and what is Stytch?

Speaker A: So I'm Juliana. I'm the co founder and CTO here at Stytch. Um, I'm, um, a software engineer by training. Um, I'm also an avid runner. I love endurance sports. Um, Stytch started because my co founder and I, uh, built out a bunch of fraud and authentication systems at previous companies. Uh, we worked together at ah, Plaid. Um, I worked on fraud and abuse systems there. Uh, also had some other experience at other companies, uh, working on ripping out auth0 and building in house authentication systems. Uh, and so Reid and I were catching up, uh, over coffee, um, one time five years ago now, more than five years ago now, which is crazy. Uh, and basically complaining about kind of like our work and, uh, what was frustrating us as one does, and the thing that we were talking about was authentication and how frustrating it was to build, um, how there weren't really the tools out there that we were sort of looking for to help us. Uh, and so ended up starting the company um, about five years ago now to basically, uh, solve that problem. Build authentication, uh, and fraud detection and prevention, uh, that's easy for developers, but gives them super powerful, um, features and capabilities so that they don't have to spend a bunch of time wrangling auth and can focus on building the core product and do so in a way that they know they're keeping their users safe and secure.

Speaker B: You have the toughest crowd to please. I keep on saying this like you're building a product for developers, the DX and the docs and everything. We're always going to dive into that, um, in a little bit and everything. But I mean, number one, it was quite funny when you mentioned that you're a runner. I was like, what is the correlation of entrepreneurs being runners? I run myself, to be honest. And at the end of the day like marathon is the real test because you have to pace yourself. And congrats on like the five years, five year plus coming in on Stitch because we keep on saying it's a marathon. Everything needs to go step by step on that. So super, super excited to get into it in just a second. But before that though, I think a lot of people enjoy these stories in terms of like, entrepreneurs and even just like working in tech in general. But where did you, I guess, like, where did you grow up? And probably the second part of that question is, was it already like pretty techie when you were growing up? Where would you have a lot of like, family members were already in tech kind of thing? What did that look like?

Speaker A: Yeah, so I grew up in Sun Valley, Idaho. It's a small ski town. Um, it's a stunning place if you ever get a chance to visit, um, beautiful mountains, etc. Definitely no tech there whatsoever. Like, ski culture is kind of the main thing. Um, and so I didn't really have any exposure, uh, to tech growing up. Um, my mom had been an investment banker, but retired, uh, before she had me and raised me there. And so I didn't really have exposure to like careers in general, like some of my friends, parents. But it's pretty small town and so there's just like limited sort of like, um, like examples of different careers that you can go into. Like, yeah, lots of doctors and lawyers and whatnot, but definitely, um, no tech. And so I had this like investment banking sort of like, um, model. Uh, but mostly what I was hearing about investment banking for my mom was like, you know, telling me the glory day worries. She wasn't working when she was raising me and so I didn't see the reality of what her day to day might look like. Um, so that was kind of always in the back of my head. Um, I loved math from a very early age. And so, um, even in elementary school I spent a bunch of time, um, sort of in my free time working on math and learning more there. I just really loved the sort of problem solving, uh, aspect of it. I think I'm a very logical person. And so it was rewarding to, um, to spend time there. And so I think that kind of like built on itself. And when, um, I was looking at colleges, it's like, I definitely, I want to do something that can apply math. I think business might be interesting, like investment banking. Um, the stories my mom's, my mom is telling sound pretty cool. Like getting to meet different companies and entrepreneurs. Like that sounds fun. Um, with like, no concept of, yeah, what the day to day of an investment banker is. Um, and so I was like, okay, I'm going to go to business school and I'll get to apply my math. That feels like an interesting career trajectory. Went, um, to Georgetown's undergrad business school my freshman year of college. And I got there and they were like, oh, congrats. You tested out of all your math classes. Uh, you don't have to take anymore. Uh, you did all the APs, and so you've got your math requirement checked. And I was like, wait, what am I learning? Then that's what I came to do. I really enjoy that. Um, and a lot of the classes were a little bit more kind of like high level. Um, and they were interesting, but I was like, I don't think I need to be learning this in school. Like, a lot of what I'm learning feels like things I could learn on the job if I go into this career. Uh, and I just happened to, um, make some friends that first semester that were taking a computer science class, uh, and it checked a requirement. And so I was like, that seems interesting. Like, maybe I'll try this. I never had any exposure before. Then, um, tried that computer science class and was like, oh, this is like so much fun. Like, it gets sort of the logical and problem solving, um, aspect of math that I really like. But I think I've always been a very kind of like, tactical person where I like seeing things and making things and like, don't want to be like, too theoretical. Um, and it really just sort of like is, is a perfect match for that. Um, and so I was like, okay, well, Georgetown at the time, um, they had like one Associate professor of computer science and no real computer science department. I was like, okay, this is probably not the place to study this if I really want to do this. Like I'm just going to shoot my shot. I'm going to apply to transfer to Stanford. Um, that seems like if I want to do computer science I can't really think of a better place. Didn't think I would get in, um, got in and kind of the rest is history. I think that just like really immersed me the startup ecosystem and yeah, I ended up doing computer science there and really loving it.

Speaker B: I think one of people would say like the turning point if anything, is this word of mouth thing where it's like, oh, you're doing one thing and next thing you know it's like if you weren't listening, if you weren't paying attention enough, it could have just like whizzed right past your head and everything. So I think that's absolutely amazing. Especially like everybody remembers their moment well. Everybody who's done like a bit of like comp sci or even high school. Their first like computer class, like for me it was comp 202 at McGill. Like that was that one class where it shows you how to do your for loops and somebody wrote something, somebody wrote something in scheme which like did factorial like insanely fast. It was so ridiculous. It was like a million factorial and it would just blaze it and do it. Like how is that possible? But anyways, I digress on a lot of that. So um, one of the highlight I actually love listening to your story is basically everybody gets into tech differently. Um, um, Honestly, out of 100 people in tech I speak to, maybe less than half of them actually did like the comp sci degree or even like had a childhood with loads of technologies in their life to begin with. A lot of people just find themselves into that. So the one thing that has been a common denominator to every technologist, everybody in tech nowadays is we've all had our moment with our first computer. I guess we've all been introduced to these gadgets and devices and everything. So I can't miss the opportunity to ask you, do you remember what was your first computer and when was it?

Speaker A: Yeah, so, uh, my family had some PC desktop when I was in elementary school and I remember kind of like starting to play around with stuff, um, then. But I think what I would describe as my first computer was, I think it was like an ibook. I think that's what it was called. One of the early Apple, um, laptops I got it in middle school. Um, and I think, yeah, I didn't really have exposure to tech, um, but I think I always gravitated towards technology and so I, like, loved that computer. I would, like, find cool stuff that I could do with it and really just loved sort of like tinkering and playing around with things. So, um, yeah, that was definitely what I would describe as like my first computer. I couldn't tell you what the first one I played around on was, but, uh, I feel like that was also like a little bit transformational for me, getting that laptop and just being like, well, I can like, do so much and I can carry this with me. And, uh, that's so cool.

Speaker B: Yeah, it really is a window to the world. Just looking into that and then just being like, oh, what can I do? The thing is, I keep on relating this part of me in terms of, obviously I do a bit of software engineering today. But the thing is, I didn't get into coding the moment I had my first laptop. I feel it's a weird thing for people to think about being like, oh, you're a software engineer. You must have been coding since we were five when you got your first computer. And as far as I know, I've asked this question to a lot of people. It's not true. Like, I probably started my first coding class was like maybe middle school. And then like some Prof. Some really good, like, Prof. Like, it was out of their time as well. It was like some like extracurricular thing. And they did that. And that was my first line of code. And I haven't coded for the next five, six years until I got into college. And then that's the next time I coded. I was like, am I a late bloomer if anything? But, um, maybe me asking you in this case, do you remember the first time you like, got in contact with coding? I guess. And what language was it? Basic 4chan. I don't know. I'm just listing extremely old languages. Cobol. I think I was more of the, uh, Java days. I was more of the HTML days. I was more of the JavaScript. So maybe on your end, when was the first time you wrote code or even got exposed to it?

Speaker A: Yeah, it wasn't until that intro class in college. Um, I'm pretty sure it was in C, which is not a good language to take for an intro to computer science class. But I ended up doing a systems concentration and wrote a ton of C and C in college. And so it did kind of hook me. I enjoyed it. I'M definitely a backend engineer. Um, but if you were more front end inclined, that class was not a good intro to what computer science can be. Um, I hear people talk about, uh, I don't know, doing HTML in their MySpace and stuff like that. And I feel like I was somewhat online in high school, but I never had a MySpace and I feel like if I had been exposed to like, more sort of like website building and design in high school, I probably would have been into that. But it's just like, never crossed my radar that like I could build the websites that I was looking at, if that makes sense.

Speaker B: No, absolutely. I love you. Called out the MySpace era and also the, for the other people who were playing neopets back then, very, very similar where you could import some HTML and then it will run it on your profile. Absolute W days, if I remember it. Um, and I also want to double click, of course. Give a little shout out to Stanford, of course. Uh, the computer science program is obviously well renowned nowadays. Even back then I'm pretty sure it was well renowned already. And um, it was such an interesting and brave moment to just be like, I'll just try, I'll just try applying. Because the thing is, a lot of people have already not given themselves a chance by being like, oh, I probably will never make it, I'll probably never do that. So even from your experience of being able to learn and study at Stanford, the question I usually ask in the sense of like, was it, was it your expectation? What I mean by that question is basically everybody goes into a program with some expectation to be like, oh, I'm better than this. Well, I'm already ready for this, I've learned everything. So by the time I get there, it's mostly just get the paper, do it, or the opposite, where you kind of like go in and you'd be like, this is the real leak, like big league now. Like, I've never seen anything, anything like it and this is where I'm going to learn everything. So on this spectrum of like, expectation of, oh, I know nothing to, oh, wait, it's going to be easy breezy kind of thing. Where did you, I guess like fall when you got into Stanford and did it end up being like that? Did it meet your expectation at the end?

Speaker A: Yeah, I think I definitely expected it to be hard and that's what I wanted. Like, I wanted something that was going to be challenging and rigorous. Um, but I think it was like far harder than I expected. And I think a lot of that is like, yeah, you're like, in classes with kids who have been coding since they were like 10 or something, right? And, like, I had written my first line of code a year previously. Like, very different sort of like, starting point. Um, the high school I had gone to in Idaho was, like, great in a lot of ways, but, like, very humanities focused. I'd never taken a physics class. I'd, like, barely taken a chemistry class. Like, I didn't have much sort of like, um, math and science background beyond, like. Yeah, I did my calculus class and I was, I think, a big fish in a small pond there when it came to, like, math. And I was like, oh, I'm like, so, so good at math. Cause, like, I'm spending time on it and I'm like, going above and beyond what my peers are doing. But my peers were like. My class was 25 people. Um, so like, 25 people in Idaho is, like, not a huge sort of, like, pond to be coming from. And so I think Stanford was, like, in a lot of ways, like, overwhelming in terms of, like, the caliber of people that you're, um, around. And, uh, yeah, taking the intro to physics class for the engineering requirements when everyone else has probably taken AP Physics. And I've never even taken a basic physics class. There were a lot of things like that that I don't think I fully sort of anticipated how challenging it was going to be. Um, but I do think I was looking for a challenge and so I enjoyed that. It was definitely hard at times, but, uh, I think I like being challenged. I like feeling like I don't fully know what I'm doing. I think that's why I'm probably a founder, is because there's like. I think in a lot of ways, like, it's just like the ultimate challenge of trying to figure out, like, um, what you're doing and building. Uh, so it worked out. But, yeah, it was tough.

Speaker B: I could definitely hear. I could definitely hear and also have other similar stories to Stanford and everything. Maybe I'll probably just squeeze this one in there because I think somebody was telling me at Stanford they very much embrace, like, pass fail. I don't know if that's fully true for every program or not, but I think one of our friends who went to Stanford, they were saying, like, oh, the reason why they embrace pass fail. And don't quote me on this. I might, I might be not fully accurate, is that the crowd that is at Stanford, the people who meet the bar to get to Stanford, is that if you have a pass fail program and the time that you're not using to study or whatever. They trust these individuals to be using that time to be doing other things that, whether starting a business or whether like pursuing like humanitarian causes and all of that. So this is probably what I understood and what I, I guess like from the outside obviously of looking at Stanford is that they very much encourage this thinking of, oh yeah, if it's a pass fail, like they encourage pass fail because for the extra amount of time that you would have from being able to do pass fail, you'll be able to use it for the good or good at the end. Is that true? Am I completely lying over here? What did that look like?

Speaker A: I think that's true for the business school but not true for undergrad. Um, you can take some classes pass or fail. But like all the class for your major, um, you have to take ah, for a grade. Uh, and they're typically like grading on a curve in the engineering department too. So it's like, okay, you have to like do well enough compared to like how your peers are doing too. Which that was always like a challenge for me. But I think like it makes sense for the business school. Like yeah, you're there to like build um, relationships and network. And there definitely were some classes that I took pass fail that were just like for fun and like I was interested in the material and like it didn't actually like matter for my major. So I think they make those opportunities available.

Speaker B: Gotcha. And obviously what you just said definitely makes sense. At the end of the day, um, I don't think there'd be a program fully pass fail from day one. That'd be interesting actually. I'll look into that at some point. But um. And yeah, the other interesting part is um, I think a lot of the similarities and a lot of the differences. For example, I studied comps and McGill. Um, my highlight classes was like algorithms. That was a great class. And then databases here and there. The classes I kind of hated like OS and some of them like building like actual chips. Those are really tough. So actually another favorite one of mine was a grad course in computer vision. So they let us play with a lot of GLS and graphics libraries and all that. Do you have any call outs favorite, like maybe top two or three favorite classes at Stanford before obviously we get into the next topic of your first full time job.

Speaker A: Yeah, my two favorite classes were the operating systems class. Um, it's definitely not for everyone but I really just like loved the challenge of it and getting sort of that low level visibility. Um, and just feeling like I really understood kind of like things, um, sort of like all the way through the stack. Uh, and then the other one I really enjoyed was like security, ah, class Security. Security engineering class that I took. Um, which I guess makes sense in terms of what I'm doing now. Um, but yeah, I think those two were interesting in different ways too. I think the security class I really enjoyed because it's like logic puzzles of figuring out, okay, how could you maybe find the vulnerability in this system and how do you think about um, that cat and mouse game of security as well. So I m enjoyed that more. Um, maybe human dynamic to it too. Of like, okay, how to, how do you build systems that are resilient and um, secure but also think about kind of like threat, evolution, et cetera.

Speaker B: Yeah. And I'll bet you anything they made you implement Caesar ciphering. I'll bet my whole life savings that there's no way you've gone through all that without actually having to do a simple thing like that. So that's awesome then. Um, and I think a lot of it is that when we talk about school and when we talk about that it's a lot of I guess academia, a lot of theory and a lot of maybe not fully putting it into practice. And it's maybe I guess like fairly interesting because nowadays when we all work in tech, whether you're finding your own business and it's very operational, it's very practical, you have to get your hands like dirty and like you really got to like find the needle in the haystack if anything. So number one, congratulations on graduating Stanford. That's number one, like the congratulations on graduating. And then the second part is basically we could talk about like our first time getting our first full time job. I feel like that's a lot of like the jump right from going from theory from a lot of learning to like practicalness. So um, I guess the question is basically what was your first role and was it like a night and day switch from having your mindset geared towards studying and preparing for finals versus actually delivering things? Um, how was that transition? Was it like night and day switch be like, oh wait, I'm working full time now and I don't have to enter studies and what did that look like?

Speaker A: Yeah, so I knew I wanted to be in startups. Uh, and so my first full time job was working at Strava. Um, there were about 100 people uh, when I joined, um, and I think that was like a good size of company to join for my first One, um, for me at least, because it wasn't like so small that it was like totally chaotic. But, um, like I joined and there wasn't like an onboarding program or anything. They were like, here's your laptop. Like, go have fun. Um, and so I feel like I definitely was like thrown off the deep end in a lot of ways and I think I maybe expected like a little bit more hand holding. Um, but also I don't mind being thrown off the deep end and enjoy that. Um, I think working for me feels like a much better fit than school. Like, I think I was always stressed about am I doing enough studying? I have all these deadlines and so much of it is solo too. Um, which is so different than how you work. I think it's very much a team sport, um, especially software engineering, I think, um, it's very much a team sport and you have people to bounce ideas off of and help you when you get stuck and things like that. And so I really enjoyed the collaboration aspect and I think I also just felt more fulfilled like building something, uh, that people were going to use. I liked building stuff for the sake of building it, um, and doing a problem set in college. But it's so cool to be able to see the work that you're doing go out into the wild. Um, I think it's. Strava especially was fun for a first job because I use their app every day. I'm a big. Yeah. Runner. Um, I was doing a bunch of triathlons, uh, at the time and so biking as well. Um, and I'd like ship something and then I would use it. My friends would use it in the product the next day, which I think was super cool. Um, but maybe we'll get into this in a bit. I think I've really found my place though, I think in developer infrastructure because I like building for other developers. And how much of sort of the engineering work you're doing is also product work in that sense. Um, I think it was cool to build features that a bunch of people used at Strava and see the impact of your work immediately. But, um, I was a little bit more removed from maybe the why behind some of the features or maybe couldn't have as strong of a perspective as I can. Um, in dev tools.

Speaker B: I think one of the cool thing that you, uh, mentioned is you describe software engineering as a team sport and I've speaking to so many people and I think you honestly are the first person to mention this and it's so accurate because the thing is like the obviously people think that like oh, you just stare at the computer and you're just on your own lane and then you just hand in whatever your homework, your code review or whatever it is. But the way you just put it in perspective that yeah, I depend on so many people on a day to day basis that it's definitely a good team sport at the end of the day day. And then um, the part of course like being able to dog food your product which is a term to say basically you get to use your own product on a daily basis. It's extremely encouraged. You kind of lob in the good practice category just because like if you do not do that you won't be able to spot out what the users are feeling if what the users are encountering and doing all that. So this is a really, really cool stories you got from that time at Strava. And one thing actually I always geek out about this is Strava. I believe it's mostly mobile apps. When you're doing dev infra I just want to double click on that part in the sense of like was it mostly the part about deploying the app just because I know like there's all these build these combo builds, whatever these test flights and all that kind of stuff. Or when you talk about Devin for was it more like the backend side where you have a million pods or I don't even know if there was that many cloud stuff back then but like a million pods and trying to like make sure that all of them have uptime and all of it. So maybe this dev infra what kind of I guess like framework technology languages that you got to put play around with during that time.

Speaker A: Yeah so when I was at Strava I started doing uh, more sort of like full stack engineering. Um and what um I ended up gravitating towards was like the API work that I was doing to support the mobile clients. Like it is very mobile heavy. They do have a web application. So like the full stack work I was doing was like front end for uh, their web application and then a lot of it was building out the APIs that the mobile clients were using. Um, and that piece I enjoyed the most. And so um, the next job I got and every job since then has been building actual developer infrastructure products. And so I think I found that the consumer world wasn't quite for me because I um, just felt like I couldn't have as big of a voice in terms of the product direction and strategy as an engineer um, versus if you're building products for other engineers and you can do that like internally at consumer companies, like building the APIs for the mobile engineers on my team. That was really gratifying because I could talk to them and be like, what do you need? And really understand the pain points and how we could think about building things better. Um, and so I was like, okay, I just want to go to a company that this is the entirety of what they're doing. And so, yeah, have ended up being sort of in the infrastructure space since then.

Speaker B: That is so cool. Because the thing is, like the best friends that I've met in tech more than anything is I was doing probably front end engineering work and that individual was doing backend engineering work. And we always had this handshake of the response better look like this. The payload that I've received from that API must look like this. And I'll promise to you that when I post it back, it will 100% be that one and nothing else. And the best people that I've seen being able to execute that are people that I've got along so well. I still talk to them today. And that's basically, I feel like something that you were experiencing back then of guaranteeing that these responses, the types, it's a date, it's a date, it's a number, it's a number, it's going to be in that JSON, don't worry about that. Um, that is so, so cool. And yeah, as we were saying, you did a couple of projects at Strava, met a lot of cool people and you also worked at Plaid as well still, um, doing software engineering. And I think like, one thing that I'm always curious about this is as you're saying startups I've gotten the chance to work at startups you got a chance to work at startups, everything could go right and everything could go very, very wrong most of the time. So something that I look back a lot retrospectively is basically good practice and bad practices. I've worked at maybe 2, 3, 4, 5 startups and then there's always good practice and there's always bad practices. So maybe if you just sum um, in terms of like your experience at working at different, uh, startups at different sizes, of course. Like, what would you love in the bad practice that you've seen and what would you love in the good practice of software engineering that you've seen during that time?

Speaker A: Yeah, there is such a range. Um, I have seen basically no project management or ticket tracking and engineers end up working on the Same ticket and not realizing that they were working on the same ticket. Uh, and then I've seen such detailed in the weeds process, um, for a small team where you're spending hours every week like planning out the story points for each ticket that um, you're working on. And I think like there's definitely a balance between the two of those. Um, but it's like yeah, maybe surprising and I think a lot of these companies are like often successful like in spite of like the bad things that you're doing. Because like no startup gets everything right. If like you're getting everything right, you're probably spending way too much time like figuring out like how to build process and best practice. Right, um, versus focusing on building a product that's interesting and matters. Um, I think the thing that always uh, I think stands out to me and is what I would describe as very much a best practice for startups is just the velocity at which you're able to ship and deploy code. Um, and do you have the right guardrails? Probably not like overly heavy handed guardrails, but at least the right testing and monitoring to be able to deploy confidently, deploy as frequently as you're shipping new features. Um, I think that culture of just like ship and iterate, get feedback, um, break things down into small chunks and pieces and just be constantly focused on the value you're delivering to users and customers. Um, I think that kind of like sets the tone and if you like have that orientation then I think like for the most part everything kind of figures its way to like good sort of um, balance of process, best practice versus like moving quickly and shipping things, um, quickly. Because I think it also helps like make sure that if you're shipping quickly and like constantly deploying, that also means that you need to be mindful of like the quality of code that you're writing and that you're not like taking down prod like five times a day because every PR that goes out is bad. And so I think it just helps force you to kind of have that right balance. Um, and so I think it's more like the culture is the best practice if you can create that culture. And um, you can still succeed with some bad practices, but it's always surprising how bad some of those practices might be. And I'm sure we have many of those at stage where we're like succeeding despite ourselves.

Speaker B: Yeah, I know it's audio only for more than anything, but I've been just nodding this whole time because everything you've mentioned, uh, I've Experienced it. And I feel like a lot of people who listen to this have experienced similar, uh, good practices and bad practices at the end of the day. And the best part about this startupy and being part of it is that you're not completely ignorant. You see the problems, you can't really solve it immediately. It's not like you have limited amount of resources. You're forced to solve the problems that matter the most and then kind of do it after. So that's where these good practices and bad practices come in. And I really like the emphasis on, yeah, like, do your checks. We have tools nowadays like pre commit. I'm a big fan of pre commit just because it does a lot of checks before it reaches even the code, before you can even merge it, if anything. So I really like the comparison of good practices and bad practices. The one bad practice I want to call out is obviously like passkeys in plain text or like people just like saving, like just keys, copy, pasting it, like putting it on Slack, putting it on Google Doc or whatever. Because obviously I think that might be a little bit relevant to what, what you do maybe today, if anything on that. Um, actually just before we jump into Stitch, which I'm so excited to get into, is you did also work for a little bit as a product manager, if I got that correctly. And this is like a pleasure, uh, to even hear from that perspective because not everybody gets a chance to do that. Um, I'm not going to brag about myself where people have asked me, why did you never go into product management? Like Perry, you're great at making Jira tickets. But the thing is, it's not just about that. Right? So maybe from your perspective of like this, this role of owning, being a product manager, what did that look like in a sense of. Was there a lot of overlap of skills that you already had as a software engineer or was it more like a net new, 80% new things that you were building during that time?

Speaker A: Yeah, so I think I listened too much to people telling me a similar thing. And I think like, even as I was like talking about like the developer infrastructure piece, right, Like, I like thinking about what I'm building. Um, I think I've always been like very product minded. I enjoy like really understanding kind of like the why behind what I'm building and pushing for like, um, you know, new like ideas and features that I have. Um, and so I was like, maybe I should try product and like, see what it looks like to do that kind of as my, my core day to Day. Um, I don't think product is for me. Um, I like thinking about what we're building, but I think like where I think my heart really lies is definitely in engineering. Um, I do think having that product experience was like valuable. Starting the company and like having to figure out like some of what we were um, building and how we were going to structure planning and things in like the very early days. But also what it looks like to be like defining product at like a, you know, six person company when it's two founders and four engineers is like very, very different than what it means to like be a product manager at scale. So um, I think it was definitely like an interesting experience but I felt like I probably index more on kind of like maybe like architecture and kind of like figuring out how we're like designing systems and like that piece more than like really going deep on like um, how we're going to build individual products. Like I enjoy doing it, but um, I think I'm definitely more of kind of like the engineering mindset of like I want to figure out like how we build this in a way that like solves the problem efficiently, elegantly, etc. Versus like getting too deep in kind of like each individual product. Um, but obviously as a founder I do spend a lot of time on product strategy and making sure we're building the right things and whatnot. Um, I think it's maybe it's more uh, kind of like a lot of the stakeholder management too of being a pm. I m think engineers and I definitely felt like I did this when I was an engineer. Undervalue PMs in a lot of cases. And then I was a PM and I was like, wow, there's so much that I have to do just to figure out what our priorities should be for the next Sprint or two. And it was an early stage startup, so some of it was just generally chaotic. Um, I think it was a good kind of experience and has informed I think both my ability, I think to evaluate and hire great PMs. And now we have a great head of product and um, she owns all of that kind of product roadmap and strategy piece for us, which I think has been a good compliment and allows me to spend more time on the engineering side of the house.

Speaker B: I think we could spend honestly a whole episode on the relationship between software engineers and product managers. I feel like this topic is very present in a lot of startups and tech world and everything. So I'm not going to super dive deep into that, but I Keep on highlighting that. The fact that you were able to do both, as we were saying, you discovered a lot of things. And when we talk about people evolving or the evolution of software engineers in general, is this well roundedness of being able to see, I guess, the concerns on each side. And that obviously helps. I'm going to speak for you, it helps a lot with what you do today. So as far as I know, it's definitely a benefit, a pro of being able to done that. Um, and also the fact when you're saying my mind is you enjoy working on stuff to make it efficient and be able to scale and be able to maintain and all that kind of stuff. The thing in my brain that I've said this phrase probably six times this week is, oh yeah, I'm building a solution that could cater to one use case, but also to infinitely many use cases. There's not really anything in between. It's like you have to make it work for one of them. But also if your solution is great and scalable, it should also support infinitely many at the end of the day. So that was really fun to hear from you. Um, but this part of Stitch, I keep on saying that like there was no surprises through your story so far as that like you were going to start something. There was. I don't know if it was a surprise for yourself, but from what I'm hearing, a lot of is that there wasn't any surprise for, for getting into a venture. And the thing is like, people know there's a lot at stake and a lot to invest in a venture, time, money, whatever you want to call it, it's a big bag of stuff that you're investing at the end. So maybe this founder story, this is probably like one of my favorite question is when did that start? Because a lot of people think about this founder story where I packed up everything, I put it all in my car, I drove to wherever else I started my business there and like you lived and breathed it. But then like in reality a hundred startups, not 100 of those like stories started that way. So maybe like your side of the story of Stytch, did it start like during your time at uh, when you're doing PM stuff or when did that story start?

Speaker A: Yeah, so I hadn't really actively thought about maybe founding something, um, until sometime into my tenure at Plaid. Um, I think in college and right after college you are exposed to so many people who are starting companies out of their dorm room. My roommate, senior year, started a company out of our dorm room. Um, so I had really good friends going on this founder journey. And, um, I, like, thought it was cool that they were doing that, but I wasn't really like, oh, I must do that. I, like, need to, uh, need to figure out, like, how to found something sort, uh, of right out of school. Um, and then at Plaid, uh, because we were working with a ton of kind of like early stage fintech companies, I felt like I just got so much exposure to different founders and companies and, um, I think was kind of like also grappling with this, like, I guess, identity crisis of like, do I want to do engineering, Do I want to do product? Like, what do I kind of want to do? Like, I really like engineering, but I didn't feel like that was kind of like where I wanted to focus, like, maybe 100% of my time. I think I wanted to like, um, explore other ideas and, and kind of like be more multifaceted, I guess, in terms of, like, the work that I was doing. Um, and I was like, okay, founding something. That seems interesting. Like, I definitely, I just love being challenged. I think that was a big piece of it too. Of like, um, I just want to feel like I'm learning so much day, uh, after day. And, uh, it feels like founding something is like, yeah, you have no choice but to learn really quickly and grow. Um, but I wasn't also like, oh, I must go found something next week. I need to find an idea. I need to find a co founder. I was more just like, open to the idea. Seems like maybe one day I'd want to found a company. Um, let me just keep focusing on learning and growing and making sure that I feel like I have like, a really strong growth trajectory. Like, I think that'll set me up for being able to do whatever I want to do in the future. I did kind of intentionally do the PM role and do it, um, at like an early stage company. Wanting to get, like, more kind of firsthand experience to like, building a company from the ground up. Um, I reported it into their cto. So I got just like a lot more kind of, um, that firsthand, like, visibility into what it looks like to start and build a company. Um, and I think that was helpful, um, also to just gain confidence that everybody's human at the end of the day. I think in Silicon Valley you idolize founders so much. At the end of the day, they're just people that are trying to figure stuff out. Um, and so I think that also helps me be like, okay, I don't need to have Everything perfectly figured out to found a company. At some point you just have to take the leap of faith and go and do it. Um, but I still wasn't looking for an idea. I wasn't looking for a co founder. I, um, was just open to the idea and continuing to focus on, okay, how do I continue to learn and grow? Um, Reid and I had become friends working together at Plaid. We joined within a few months of each other, um, when the team was pretty small. He was originally on the go to market team and then he was on the product team and we just like got to know each other. We did some hackathons together. Uh, I think that was like really fun because, um, he would come to me with like, um, sort of like a business case for like a product and we'd work on like defining like how that product was going to work. I would build the product and then, um, we would like pitch it together. Uh, and that's like basically what starting a company is like. And so we kind of like trialed that, uh, during hackathons. Um, and that had been really fun. Uh, so when I left Plaid, we just like decided to stay in touch and like get coffee every other month or so. Uh, and so we were getting coffee and basically complaining about authentication. Um, he was struggling with some stuff in his work. I was struggling, um, with ah, a different project. And we were like, we're both struggling with the same problem basically at two different companies. Like, that's interesting. That feels like it's signaled that, you know, maybe there's something here. Um, and we kind of like went off that. That coffee was like, um, before the holidays in 2019. Um, didn't talk about it as like, oh, maybe we'll start a company. Uh, it was more just kind of like, this is an interesting idea went off and like, didn't really, um, talk about it too much until, um, sort of like early 2020. Uh, and sort of kind of like the digging in a little bit more, talking to people that like, maybe could be users of this product that we were at that point like thinking about maybe building, um, just trying to understand like what people were doing for authentication, what products they were using, what they thought of those products, and um, just like sort of like explore and get feedback. Uh, and then Covid hit. And so all of a sudden, uh, we were sitting at home, um, and doing nothing on the weekends. And so ended up having like a lot more time to dedicate to this. And um, I think other people were also like sitting at home and available on Zoom. Uh, and so we just, like, did a bunch of calls with people, uh, to try and get their feedback, and we're able to kind of like, accelerate that because everyone was sitting at home during COVID Um, so that kind of happened, like, through the spring, uh, and there was no, like, clear decision point, um, where we were like, we're gonna start a company and, like, quit our jobs and do this. Like, at some point, we were both just kind of like, yeah, we're gonna, like, tell our, like, managers that we're leaving to go start a company. Um, and it just, like, felt inevitable by the time we got there, because I think we had just, like, built up so much conviction, um, in the idea. I think we'd like, spent enough time kind of, like, um, working with each other and feeling like we felt confident in starting a company together. Um, so kind of just all snowballed, essentially, where just gradual build over time, um, got to the point where we're like, okay, this just obviously is what we have to do. We must go start this company. Um, and I think if you told me that that was going to happen six months when we first had that conversation, uh, six months before it actually happened, um, I. I don't think I would have, like, had confidence that this journey was going to end in us starting a company. Um, it was very much kind of like wanting to feel the pull of the market, wanting to feel like we, um, felt like we would be like a good founding, um, pair and things like that. Um, and it was, yeah, it was weird time starting the company. It was like, yeah, June 2020. Um, we were, like, sitting at home, like, for a while. Reed went and was, like, living with his parents, and then I was, like, living with my mom. And we were, like, trying to figure out if we should, like, come back to SF and, like, be in person. And ended up doing that. And, um, I think that was, like, super valuable. But, uh, it was like a weird time of, like, trying to figure out, okay, one, how do we start a company? Do we quit our jobs in the middle of COVID Like, there's so much unstability in the world. And, like, is this the right time to found a company? I don't know. And, um, I think, yeah, there's no perfect time, and sometimes you just gotta take that leap and go for it.

Speaker B: I think the definition of leap of faith, you've lived through it in the sense of. A lot of us remember that time. I think it was around March or something, March 2020, when if you were working on A lot of tech, they were like, just go home. Literally, do not show up. Uh, just go home. We're gonna get fined if they see you in our office. So that's kind of how that happened over there. So. And even a lot of the part where it's like, how do you do this transition? As you're seeing, like the idea, once you have an idea, you don't immediately just drop everything and then just jump into it immediately. Right? A lot of times, as you were saying, it kind of just like it pecks at your brain. That's how I describe it. It's always there. It's always there. And then the fact that as you're seeing, I think one word that I wrote down after listening to talk about so much about that is organic mostly. Um, because we were talking about coffee. I was like, oh yeah, organic coffee. But I wasn't really talking about that part. I was like talking more about the fact that the relationships and the people that you bump into in Silicon Valley, in the Bay Area, it seems so organic towards building stuff. It seems very organic towards throwing ideas out. And regardless if you do anything about it, that's like the sudden, like, that's like the, I don't know, the culture, the environment that it's so hard to replicate unless you're physically there. So I really do like the story because that was an outcome. Stitch is an outcome of those like organic, um, interactions when that happened. And then as we're seeing, like, okay, leap of faith, when do I take the jump? And of course like you're, you've been on an absolute journey so far. And I obviously want to take a second to talk about the product itself because one of the recurring theme that you were talking is you were encountering problems. You both, I mean a lot of people, not just you both at the end weren't counting problems. So this is you. And also read, read biggingly stampo, if I got that correctly, the co founder of Stytch. Um, um, you're encountering a lot of off related problems. Um, um, I think working in tech you're nearly supposed to be encountering them unless they use Stytch obviously. But okay, so now when we talk about Stytch, we're talking about authentication, we're talking about two FAs, we're talking about MFAs, we're talking about SSOs, we're talking about all these. I mean we're obviously going to diversify a little bit on it, but even on a very, very high level, as somebody who works in tech, but have not built anything auth related. Do you want to I guess like describe what Stytch is for developers uh, building just anything nowadays?

Speaker A: Yeah, so Stytch is an authentication and fraud detection platform. Um, the authent fraud pieces you can get together, you can get them separate as well when it comes to authentication. Uh, basically what we built is um, SDKs, APIs that make it really simple for you to build very complex authentication flows and requirements uh without having to become an auth expert and think about that and you can own your user experience. You can um, make it look and feel like your application um etc. Uh and really easily cater to m the myriad of different auth requirements you might need to um, service. This can look very different if you're building a consumer app versus a B2B like multi tenant application. Um, often the demands are different across the two. Like in consumer you're mostly thinking about M like user conversion, retention, etc. You want it to be secure but you also want to reduce friction so that consumers you know, um, aren't dropping off as they're signing up or coming back um, to uh, log in again. Uh, and so we have sort of built our consumer platform to have that in mind um, to sort of optimize for user experience experience give uh, you sort of like an endless list of options that you might want to offer to users. Whether that's like um, sign in with Google email password, um, SMS one time passcodes, pass keys like you name it. Um and then in the B2B world like the requirements that you're having to service there are often dictated by your customers and their authentication requirements. So you might need to offer you know, SSO for one customer, you might need to offer uh, username, password and um, some two factor authentication for another customer. Uh and oftentimes like servicing all of those different requirements requires you um, to build a ton of logic uh, to figure out like what um, someone can log into a given organization with and if they're able to be part of different organizations. And if so like do those authentication requirements differ across those organizations? Basically can go on and on about like all of the kind of like behind the scenes things that we're doing to make this really easy for you. So you all you have to think about is like customer A logs in with SSO M and in many cases you don't even have to think about that because you can just embed our SDKs in your dashboard. They can choose what they want to do, they can set up their SSO connections, etc. So we're abstracting all of this like annoying complex logic and making it really easy for you to build um, these, these requirements. Uh, we also do the fraud detection and prevention and part of the reason for that is um, our background at Plaid was um, uh, doing a lot of kind of like protecting against things like credential stuffing, account takeover attacks, etc. Uh, and I think it's like um, it's not super fair to like sell authentication and not have fraud detection built into it because at the end of the day like what you're selling with authentication is um, protecting user accounts and there's so much rampant fraud on the Internet, um, that it's just kind of table stakes, uh, to make sure that you're able to protect against things like bot attacks or um, account farming or all these different um, sort of abuse vectors. And so we built a product there um, in house that ah, does things like device fingerprinting, anomaly detection, et cetera. Um, and that you can also buy standalone if you're just looking for the fraud detection prevention as well. But um, I think the combination of the two um, is where we're most powerful and really meant to just solve this problem so you don't have to stress about it. You can offer your users whatever auth methods you want and know that their accounts will be safe and protected.

Speaker B: Yeah, and I have to emphasize that you're solving a problem. The thing is, a lot of this conversation, uh, I'm sure you get into a lot of these meetings, a lot of devs get into the meetings is buyer build. This is the conversation of like we could just build it, we could just do it in house, we could do all this. Like actually if I, if I may, I'll probably take like a minute to be like if I were to try to solve this problem as a dev, what do I need to do to be able to handle login? A lot of times we talk about, oh well first of all you have to have a client side application. Not always, but client side application, a server and then some middleware in between. Pick your favorite framework, I think a very popular one I think in JS like Passport. I think that's the one that I remember using at some point before. For where take, take that. It's going to provide you, you know, very high level out of the box like authentication. And then by that point you could build your own like oh, I'm going to build two inputs. One of them is for my username that's on the Front end side and then the other one's my password. Then when you press the button it's going to make an API call. But then when you think about all the security behind is like how do you hash all of it? Where's the tokens, where's the sessions? Like what, how do you even build your middleware? Do you build it very, very close to your front end and the backend? This is like hours if, like, if not weeks of works that you're spending as a dev doing um, just because I've done that before. So this is kind of when we're talking about like the contrast, right of like how you are spending your time to build a product that solves this overhead of I could, I could say over probably a million people daily are building. They have like dedicated teams within actual like uh, organizations that are just focusing on this. This is what you're trying to solve with Stack Stitch. And this is kind of where, when you're mentioning the products where the different, I guess like pillars, however you want to call it, there's the authentication for B2B and then the authentication for the consumer apps and also the fraud detection. Um, we will get back to the fraud detection because we're going to throw out the word kyc and we'll get into that in a little bit on it. So I definitely see how um, the appeal of how do you Stitch. This is one thing I want to dive into is how do we use Stitch? We keep on saying that like it's a product, it's available out there. You could honestly start using it in the next hour if you really wanted. So if we want to get into that part is whether I'm a dev or whether I'm somebody in a tech org or somebody who's like you know, just technologists and fascinated by it. What are the, I guess like entry point to integrate and use stytch today?

Speaker A: Yeah. So uh, you can go to our website and sign up. We have some onboarding to sort of like help you um, navigate and try things out. Um, and the way that people are typically integrating is um, using one of our SDKs. One of the like uh, I think differentiated things we've built is um, kind of like three different tiers of how you could integrate. So um, you could integrate using our uh, front end SDKs and front end components. Um, that means that like the UI of login is fully built for you. You can style it however you want but you don't have to think about like error handling or um, dealing with uh, things like uh, in the B2B case showing all the different organizations that a user could get into and all of these like edge cases, et cetera, you just drop in the front end components will handle it for you. Um, the next option would be using our headless SDK. So that's still a client side um, integration for sort of like this login experience. Um, and that basically lets you own um, the ui. So if you want to build like super custom ui you can do that. Um, in both of those cases we'll handle session management for, for you. Um, because we have that client side touchpoint we're able to um, validate the session, refresh it, et cetera. So you don't have to think about that. Uh, the third option is a backend integration so if you wanted to you could just fully use our backend SDKs to build the entirety of this. That means that you have to build the front end logic and um, handle that yourself. Uh, client side you have to handle things like the session refreshes and whatnot. Um, but we find that if you have like a super complex you know, in house auth implementation today, um, typically people will migrate to that backend integration because it gives them um, so much of that control over um, kind of like the user experience but still abstracts away um, all of the complexity when it comes to auth. So um, you kind of have to like pick and choose which one of those you want to start with. The front end components are definitely the easiest to get started with. They handle the most for you. Um, and so can, can drop that right in and um, could probably have auth built with stytch by the time we end this podcast if you really wanted to.

Speaker B: I'm not surprised because I was looking at it and I like the fact that you're seeing like it's by level of complexity. Right? The drag and drop button, a lot of people have done it with other examples as well but it's a snippet of code. I mean even some non technical website lets you do that. So this is a really great feature because one thing that I feel like you guys have definitely paid attention to is there are different kind of developers out there. There's some developers that just wants a solution done. So they'll have a login page, drag and drop and you have the imported component and then you put it there. But then there's other developers who will curse at every single design detail and be like but I need this animation, I need this hovering effect on that button. So yeah, you also cater to them by providing this like API or like this, this middle management, middleware system where you're able to, hey, skin it however you want. We have all the APIs that you're able to do, all the functions that you need and then you're able to call that. And then as you're saying you also have, you could manage it from the server side and that's obviously like super, super powerful. I um, was reading the docs as well. Like many, many languages, many different frameworks. Like that's definitely a highlight of how, I'm guessing from, from my external part is that you pay attention to the different kind of developers and the different kind of lift that somebody wants to invest in it. Um, the other part to it is when we're talking about I guess like the difference between B2B and consumer apps, those are like the two different parts to it at that point. Um, we are mentioning that like for typical users, if I'm working on a project, like even my side project, I could integrate with Stytch. When we go to the B2B side, do you still expect also the engineers from different orgs to be interacting with Stytch directly or are you looking more for like system admins and people who are configuring like databases or operational type engineers more kind of role? Is that like the difference between the user base for both of those authentication? I guess, like products.

Speaker A: Yeah. So the like customer that we're selling to in either of those cases is still um, like a software engineer building authentication for their company's end users. Um, it just depends on whether those end users are like other businesses. Um, so is this like a SaaS product that like you know, Stitch would buy? Right. Or is this like a consumer app that like you as an individual are signing up for? Um, obviously there's like some apps that kind of like straddle the two like notion for example I think is a good example of like um, sort of this like prosumer and there's team elements but also a lot of people use it individually. Um, our B2B product is designed to fit that use case as well as the more sort of like enterprise um, B2B company use case. Uh, so it's yeah, engineers that are selling to and then their end users could be anyone. Right. Like a B2B SaaS company might have other engineers as a user like Stitch does, or it could have um, IT and workforce etc. Um, the piece that we build that they sort of like um, would be used More heavily by like an IT admin, etc. Is our, it's called our admin portal. Um, so we, for example Stytch, of course, dog foods, our own product, we use Stitch for authentication. We use the admin portal in our Stytch dashboard. Um, so if one of our customers wants to set up sso their IT admin can um, go to the Stytch dashboard and go to the like, configuration settings and set up their um, like workforce IDP that all of their employees need to log in with. Um, so that's the piece that sort of touches like IT and more workforce authentication. But um, we're not building any sort of like workforce authentication. So we're not selling to like companies to use for like their internal employees. Ah, to use for login, for example.

Speaker B: Yeah, that makes a lot of sense because like every time we think about, or at least every time Perry thinks about product, like who uses it. So like the distinction that you're putting on there, you could definitely see like it impacts the decision you'll make for the next feature that gets built on one of those. So that's really, really cool from how you're sharing that. Um, this other branch that I definitely want to talk about, the fraud and protection branch of Stytch and everything, because I never always get the chance to talk about this. I do work in fintech. So that's the fun part about this is we throw a lot of these concerns right, like identity theft or even just like spoofing and using somebody else's IP and then all that kind of stuff and eventually everybody leads into this conversation of like kyc. So I think very on a high level of like, number one, what is kyc? And then the other part of uh, we're also going to dive into how it's built in a sense of like it's a tech podcast at the end. We'll have to think about it a little bit. We're not divulging any secret, just going to talk about a little bit behind the scenes, but very, very briefly, just to begin with, fraud, production, um, risk. Kyc. What's the relationship between all these words that we're throwing out at the moment?

Speaker A: Yeah, so all of these are kind of like, I think different pieces in the stack to identify like, who is the user that's either signing up or logging in? Are they who they say they are? Um, can you verify that identity? Is that person someone that should be able to sign up for your app, um, and should be able to use it, or, um, Is this someone that is potentially risky either because they're trying to pretend to be someone else or, um, because they have like a history of ah, abusing the platform or something like that. And so kind of depending on the use case, you might have um, different needs. Like in fintech, KYC is super important because, um, you need to make sure that you're able to verify the identity of your customer, right, so that you can um, know whether they are like, who they say they are or whether they've stolen some identity and whether they should have access to financial products. Um, we don't play too much in that KYC space, but we'll often see people plugging us in alongside kyc. And also unlike returning, um, login, uh, so where sort of Stitch fraud detection prevention is playing is really around kind of like um, account security, so identifying if there's like bot attacks happening, uh, maybe because it's credential stuffing. And you can also, uh, use our product, like identify bot attacks on endpoints that are not your login endpoint as well. Um, if someone's trying to um, script uh, your product, uh, to get access to um, some resource or something that might be valuable, uh, that is something we can detect as well. Uh, and then verifying that the person who um, is trying to log in is not someone who's uh, abused the platform in the past and is now like creating a new account and trying to pretend to be a new person so that they can get access to like, you know, some free credits or a bonus or something like that. Um, so we're like Stitch fraud detection prevention is really coming into play, is kind of around like identifying um, like the type of request this is. Is this a bot? Is this a human, um, is this a returning user? Is this a user, um, that's new to your platform and getting sort of like signals on that.

Speaker B: This whole cat and mouse game of like trying to know who's playing this game to begin with. If we were building our own solutions, it's always endless, like there's always going to be new ways. So I think a lot of times when you're talking about how Stitch has this product, but it's also, I'm assuming it's that it's being built like programmatically and it evolves organically in the sense that like it's the product you'll see from Stytch, at least on this main or anything, is that it'll be different in a month and it'll be different in the next month just because it needs to be like that. And that's why you guys are doing the hard lifting, so that other people could benefit from that. So it was really cool for you to mention the different type of concerns like as we're seeing like the bot attacks, the DDoS, the credit stuffing and all that. I think if I want to lean into the, I guess like the tech side because obviously Perry's brain is always about like how in the world did you build this? Obviously I'm not asking you like oh, what's exactly a line of code that you wrote today? Do that. But I guess my question would probably be in the sense of after listing all these concerns of like bot attacks and like cred stuffing is that you obviously have to build some type of technology and some type of measures. Uh, to be able to handle that and to be able to build those you need a specific kind of I guess like engineer or workforce at the end of the day. So um, I guess the first technical side to this is basically what does I guess like a lot of the focus of engineers at Stytch worry about? I think like this is. You're probably the best person to answer this if anything is basically, I'm gonna guess you don't need that many front end people. I know you have a marketing website, I know there's lovely portals and all of it. But whenever we talk about like behind the scenes, like whether you have cron jobs, whether you have like API like monitoring and all that kind of stuff like that is. That seems very backend heavy. So my techie question is yeah, what does the typical engineer look like at uh, Stytch? I know there's no typical engineer, but maybe from your description.

Speaker A: Yeah, I think the first interesting way to think about this is that I think just over half our company is engineers. Um, and yeah, that's people not that have an engineering background that are software engineers at Stytch. Um, and I think that is part of the equation in terms of the type of product and business that we're building. It's very engineering and just generally EPD driven in terms of, of the product. And um, we focus a lot on like yeah, building really great products and that's where a lot of our like employees are spending their time. Um, I think uh, there's, there's kind of a range. I think we definitely um, have some amazing front end engineers. Like developer experience is like I think you uh, either make it or break it when it comes to things like docs and like integration experience. And um, so much of that is kind of like in those um, in those first touch points that you have with like our dashboard docs etc. Like can you really easily understand um, the product and how it's going to work for your use case etc. So we do invest uh there quite a bit. But um, I think yeah to your point, uh, a lot of our product is, is infrastructure. It's the APIs, but it's also the scalability reliability of those services. Um, so the majority of our engineers are, are going to be somewhere in sort of like the back end camp. Whether that's like product engineering back end or like a more sort of like um, platform backend engineer, um, can number on the infra side as well. Um, and then we have a smaller um, sort of like pod of um, more kind of like security and R and D engineers and they are investing more in kind of like some of the cutting edge uh, products that we're building on the fraud detection side. Trying to make sure that like you were saying, like that product really does evolve. It's probably evolving even more quickly than um, month to month. Uh, just because like the threats are evolving and we need to make sure we're staying on top of that. And so they're um, working uh, more on kind of like that R and D aspect. Uh, so yeah there's, there's kind of a range. But I think the way we think about ourselves is like we're critical infrastructure. Um, our uptime is our customer's uptime. And so a lot of the company is um, focused on building that and scaling that.

Speaker B: The more you list the more I was like oh yeah, that's all the pieces. Not all, but a lot of the pieces. I need to have an organization to be able to tackle a problem. People saying that oh I could just build my own solution is I think you could build a very simple solution. But the stuff that you're not able to see, the stuff that you're not able to predict, that's really where you get the expertise of trying to figure out oh maybe you obviously need a bit of research, maybe you need a bit of thinking in terms of what is the next threat that's coming in. Um, but even outside of just the vein of fraud protection and risk and all that kind of stuff, I love asking this question actually because when we have a ah, product that offers an SDK is I've asked this question to other engineers to be like do you know how to build an SDK? And a lot of times you'll see A rough answer to be like oh yeah, it's because you have to host it on an NPM package and then people could download it on NP kind of thing. So maybe obviously as a domain that you guys work so much into providing an SDK for the people, I guess like a very high level thing for the people who uh, don't know how to build an SDK, just like me for a long time is how do you build an SDK? Is it always in for example JavaScript or Typescript or are you able to do that in multiple languages? So um, I guess like maybe a 101 on how to build SDK with Juliana. What would you say?

Speaker A: Yeah, so we have quite a big range of SDKs and there's kind of two different ways that we're actually like building those. Um, so we have our more sort of like front end SDKs and that's like um, JavaScript, uh, iOS, uh, Android, React, Native, etc. Like we have native SDKs um, for all of those different platforms. Um, those all have kind of like the UI components etc. Um, and so we have an engineering team that's, that's fully focused on building those. Um, and yeah, to, to what you mentioned, like typically um, there's some distribution uh, for packages in each of those languages. Um, so you're in, you're building in and uh, releasing it via whatever the like native package manager is for. Um, like Swift or JavaScript or whatever it might be. Um, and the other category of SDKs we have are our backend SDKs. So those are more sort of like handling just kind of the API and backend logic that uh, uh, you might have to build out yourself and you can, you can build all of that out yourself. But these are nice you know, helpers um, that basically if you were to like abstract away how you're interacting with an API in your own code base, that's essentially what an SDK is. It's just like instead of, it's like some package within your application, it's an external package that you're installing. Um, it's pretty cool. We've done on the backend SDK side. Um, so there's a lot of custom logic that we need to include there but a lot of it is also just like boilerplate. Those nice sort of um, helpers for calling the different API endpoints and abstracting away how do you make an HTTP call in Go, for example. And so we've built um, auto generation for those. Uh, and the reason we built that in house is because there is custom logic that we need to involve and so um, to just like sort of auto generate, uh, to our API spec back in SDK is probably wouldn't be as value added as we think they can be. Um, but we also don't need to write that logic for every single endpoint in every single language that we support. I think we support like um, Java, Kotlin, uh, Go Ruby, Python Node, um, Rust. So there's like many different languages that we support. Um, and if we had to like custom build out every single line of code and every single one of those SDKs, like that'd be a ton of work and probably also error prone etc. Um, so we built some really cool tooling that auto generates that it also auto generates docs so that um, all of these, these different endpoint or all of these different SDKs are well documented for every endpoint, et cetera.

Speaker B: Writing a tool to convert one language of code to another language of code has always been one of the coolest thing you could do in tech. I keep on saying this is you can build cool websites great, you can build cool servers great, you can write amazing, like. But literally taking the syntax of a language and convert it to another one. The fact that, hey, some people at uh, Stitch gets to do that on a daily basis. Absolutely jealous on that. I don't even know if I'm allowed to ask this question, but what's the source language like then? What's the language? Is it like assembly? Is it like very, very native languages or how does that work?

Speaker A: Yeah, so the crux of how we're defining our APIs is in Proto buffs. And so we're using the proto definitions, um, to then basically um, run a script that's like converting those proto definitions into um, the different languages.

Speaker B: This is so geeky of me, but I'm so glad I asked the question in the sense of like, oh, that's one way you could do it. Yeah, that's actually a pretty far away. Um, sorry. To be honest, I ask these questions for myself. I don't really care what other people wants that wants to know about this is really just for Perry to geek out on. But, um, the tech side is always fun. Like it's always so much to build on top of it. But the thing is like, there's also the highlight, um, on your side of the operational bit. Right? Of course you're managing a product, of course you're managing the tech behind it. But there's also the part of like looking forward of what's on Roadmap and what we should build before other thing. Because I'll bet you anything that Stitch wasn't built over overnight is that you had to decide what piece came first and what piece came after that. So I think on more of the operational side and more looking forward, my question would be I guess like how do you decide moving forward? Basically you have so many things on your roadmap and I guess you could probably answer that in the sense of like. Well I mean of course it's the business side but also the technical side of making decisions. People talk about tech debt, people talk about a lot of reasons why we shouldn't do one or the other. So um, what is your perspective on how to handle this upcoming roadmap? So many features, so many tech you want to build. Uh, maybe if you have any philosophy you want to share about that.

Speaker A: Yeah. So I think we always try and strike a balance of like investing some in what I'd call kind of like R and D, more experimental, um, product development, uh, things that we have ideas about but want uh, to kind of like proof of concept and test out, um, and maybe like yeah, test out whether this is something that we want to invest more resources in. Um, um, it's a pretty small percentage of overall time that we're spending. But like having some of that I um, think mentality is, is really important. Um, I think next comes um, sort of the features that uh, we think are going to be really critical. Ah, uh, and might be like maybe a little bit forward looking or maybe more sort of like innovative and differentiated and aren't necessarily something that like our customers are asking us for but based on what we know about sort of like um, the competitive landscape, uh, best in class auth and what people are building, you know, in house. Um, the best uh, sort of companies out there when it comes to, to authentication. Like what are some of the innovations there? What are like the industry standards, things like passkeys, um, what other trends are we seeing in the market and industry that we think might um, impact authentication and kind of like aggregating, you know, all of this sort of like um, industry, uh, context to come up with what are the things that we think um, could be interesting differentiated and um, get people really excited about Stitch. Um, and then there's a category of kind of like maybe more table stakes features or things that um, we feel like are an existing gap in our product. Uh, for the first few years of the company like a big chunk of our time was going to these Things because authentication is just a really big space and like you need to have all the things, you need to have passwords, you need to have all the different oauth integrations, you need to have mfa, you just, you need to have those or like people can't use your product. And I think now is an exciting time. We um, are pretty comprehensive there. There really aren't too many of those like big features that if any that we don't have at this point. And so now there's like more interesting kind of like value add things that we're building. Um, but a lot of that will also come from like customer uh, feedback and like what we're hearing um, from our customers and what they want. We try and be pretty, I think like customer centric and um, I think we're opinionated about what we build. So we don't like build things one off for like one customer that we think no one else is ever going to use. But you know, if there's a feature that we've had um, in the backlog for a bit and there's a customer that's like this would like be life changing to me or I can't use your product unless you build this. Um, we're willing to kind of like shuffle things around and uh, build things especially if it's like a more interesting like complex feature. Like it's great to have design partners for those and people who are beta who will beta test it and like give you good feedback. Um, so that's kind of like more on the feature development side. And then I think um, we try and focus on things uh, that are more sort of like foundational that will either um, improve kind of like reliability, stability or like velocity of our team. Um, so I think that's how we think about like investing in tech debt. Ah, is this going to like accelerate uh, development? Because it's really hard to work with this part of the code base. Is this something that's caused like you know, maybe an incident in the past or we think is like high likelihood that it might in the future and super sort of like dangerous to have and we should make this easier to work with um, or other kind of like foundational things that just like improve um, you know, maybe testing or ah, monitoring and alerting our um, scalability of our systems, et cetera. And I would say there's like a pretty decent chunk of time that's going to those types of problems as well because um, at the end of the day reliability is part of our value prop and so need, um, to make sure we're delivering on that.

Speaker B: I really like how you just highlighted all of it. First of all, design partners like user feedback. If users are giving you feedback and you're not using it, what's the point? So a lot of it is that it really does help you guide the project and everything. And of course, on the other part, part of how you tackle your philosophy, tackling tech dev, it's a lot of understanding and balancing both of them. That's why we keep on saying that your plate is absolutely full of stuff to do. And then I'm assuming there's a rice chart down somewhere where obviously you're going to do the estimation of the efforts and to reach the impact. So that's always a fun part of maybe more the product brain going into this, um, framework more than anything. Um, I can't let you go without asking this question about we love technology. At the end of the day, we love software, we love apps and all that. So coming back to Juliana, I guess, like, what apps you need in your life, whether it's a phone app or a computer app, uh, we talk about efficiency, we talk about some people cannot live without Slack, for example. Some people cannot live without other things. So for you, maybe, like, I don't know, top three, top whatever you want, like any, any apps that you, you really embrace in your life today.

Speaker A: Yeah, I think I'm definitely a Slack person. I, like, I get feedback that I'm like, super, super responsive on Slack, which I think is like, both a compliment but also, like, something I could be better at, not getting distracted. Um, I think I'm pretty good of, like, you know, balancing when I really can't be distracted and like, triaging. Um, but I think there's, like, so much value in just, like, making quick decisions, unblocking people, especially in my role. Like, people will be waiting on me for things, and so I try and be like, super on top of it. So I really do love Slack. That's probably like the, the. Maybe one of the work tools that I think is, um, most, uh, important for me. Um, I think both in work and personal. Um, and I like these for different use cases. Maybe kind of cliche, but I really like, um, Claude for kind of like helping me draft things, like their projects, um, just make it really easy to, like, give a ton of context. And I think I am really good at, like, editing, um, but writing something is, like, really hard for me. And so I feel like I deal with writer's block, and so it's been really cool to like get to use AI to like help me kind of like get over that and like throw unstructured thoughts at it and then get to edit. Um, and then I think chatgpt I really like for asking like just, I don't know, basic questions about like my life that um, I like maybe would go to Google for. But I want to like actually get a more in depth answer. Like I've had a foot injury and I was like working through how to like diagnose what the foot injury was and like how I should rehab it. And yes, I should probably go see a doctor, but um, I would probably do the same thing just using Google and be more frustrated on my own or like something around my house breaks and I'm like, I don't know how to do this thing. Instead of like calling my mom, I might use ChatGPT. So I think both of those have been like kind of like new tools that I feel like really in the past few months I feel like I've gotten a lot of um, a lot of unlock from. Um, I think another one that is newer and has been cool and you can tell I'm like maybe a little too into AI. I don't know. Um, but Cursor has been really fun and I think especially for uh, the level of code and how often I'm writing code right now, it's not super frequent. I'm not in the weeds all the time. Um, and it's really helpful for like helping me like build context quickly and like dive into things or like do a quick thing here or there if I, I maybe haven't been in the weeds as much. So m. I think that's been. Been fun to work with. So, um, those are, those are maybe some of the main ones. This is like, maybe not. I don't know if this like fully fits into this category. But um, I love being able to take pictures on my phone of my dog. I take like 10,000 photos. I feel like um, a month of my dog and getting to share those photos, um, and uh, yeah, just getting to capture all of that. I think that's probably. If you looked at my app usage on my phone, the camera app would be one of the top ones.

Speaker B: Yeah, I think the spread of apps that you were sharing, it's absolutely fantastic. Obviously I led into the productivity app. So we're talking about apps that we improve, embrace and those are all great examples of how, whether it's personal business, whatever, it does enhance your life and be able to use them. Is just another joy of seeing technology evolve. I love asking this question because every time I ask this from year to year, whatever, there's always new stuff in the answer. So that's absolutely my pleasure.

Speaker A: On that.

Speaker B: Um, I did highlight this big question that I wrote over there, and you kind of partially answered it, uh, shortly. But do you still get to touch the code? I asked this to a lot of technical founders because sometimes they'll be like, yeah, the engineers don't let me touch the code at all anymore. They've explicitly banned me from touching the code. So maybe my question to you is basically, yeah, what does that situation look like at Stytch at the moment? Are you still able to write code and contribute to that?

Speaker A: Yeah, I don't write too much code today. Uh, and typically the code I am writing is more around examples or demos or stuff like that instead of core application code. Um, I wish I could spend more time writing code, but the amount of time I have to spend on something like that, it takes so much time to build the context and make sure that I'm gonna do it in a way that's not gonna, um, piss off the engineers, because I am maybe a little bit more fast and loose with how I might operate or something like that. Um, but also I think, uh, in terms of the leverage that I can have and where people need me, I think that's more for me personally, I want to write code, and so that'd be more of a fun pursuit versus actually what's most critical for the business. And so, um, I think I focus a lot of my time on people management. Um, I manage a couple of our engineers and our engineering managers directly. And so there's a lot of time that's going into that. I, um, manage our head of dev success, our head of product, and like all these other people too. And so I think I focus kind of on, like, how can I, like, provide leverage by giving context, um, unblocking people, etc. Um, and so that's where, where the bulk of my time is going also to, like, sales calls or all these other random founder things that are coming up. Um, but, yeah, try and find those opportunities that are, like, they can be more of a side quest and like, something for me to, like, test out using cursor or other new tools and have fun kind of experimenting instead of something that's, um, core to our business logic.

Speaker B: No, absolutely. The hats are infinite. The hats you have to wear is absolutely infinite. And I think the best part maybe, you know, this definitely is that Writing code is not the hard part. It's the follow up after. It's the fact that once you put into review and the fact that if it doesn't go through review, then has come back. And once you engage in that path, it's a loop, it's whatever. So the overhead that people, when we talk about writing code and not be able to day to day, is that we understand the backside to it. We understand everything that comes after it. So I feel like that's something that is so cool for you to share, is that it's not because you don't get to write it daily, is that you're disconnected to it. No, it's because you definitely understand the topic, if not more than just writing the code. So this is super, super cool of sharing.

Speaker A: I think that's exactly it. And I think that's kind of like when I evolved my role out of, like, writing code was when it was like, okay, I, like, wrote the code, um, and now I need to, like, put up a pr and then I have meetings for, like, eight hours the next day, and I don't have time to, like, come back and like, um, revise what I, what I need to. And then I have to, like, go to a bunch of other meetings and then I have to deploy it and like, the context switching and also just like, lag time, um, is like, yeah, really hard to manage. And I think it's like, I wish I could do more of it. But also, writing code is not the tricky part there. It's making sure that, um, you're doing the code reviews, that you're deploying it, you're monitoring it, et cetera. And, um, doing that spread out over weeks is not a super fun way to be shipping code.

Speaker B: Yeah, ditto. I'll echo that a billion times in my life. I see myself in that. But thanks for sharing so much of that. I guess the last question that I have for you is basically when we talk about North Stars. You've worked on so many great projects, not only just at Stitch, but just from the moment of never really thinking about getting into tech and then getting into Comp Sci and then getting into should I found my own project? Should I do that? So my question to Juliana is, what is your North Star? What has been the guiding light for you? And if anybody hears this, be like, oh, that's a great guiding light. What could you say about that?

Speaker A: Yeah, I think I enjoy feeling like I'm challenged and, like, learning every single day. Um, and I think, want, uh, to feel like I did sort of like the most ambitious thing that I could do and, like, didn't sell myself short in terms of, like, where I set my aspirations. Um, and so I think I really m just try and find those opportunities that feel like a really big stretch or are maybe a little uncomfortable at the time time, um, and feel like really big sort of like personal growth opportunities.

Speaker B: And I think I could definitely use that as a mantra day to day. So, honestly, on behalf of Perri and on behalf of everyone, Julianne, that was absolutely amazing, all the stories that you shared. And I got to ask you, where could people find more of Juliana and where could people find more of Stitch?

Speaker A: Yeah, so, uh, my social handles are, uh, ulianaelam. Find me, I'm on Twitter, LinkedIn, et cetera. Um, and then stych is s t y t c h dot com and

Speaker B: of course all the links will be shared in the description notes below. So definitely check those out over there. But yeah, honestly, thank you so much for being on the show. We obviously will keep track of everything coming out of Stitch, all the great products coming out. And for the rest of you, we will catch you on the next one. Thanks again, Siya.

Speaker A: Thanks.

Speaker B: And that was Julietta Lapp, co founder and CTO of Stytch. All the links are shared in the description notes below.

Speaker A: Go check them out.

Speaker B: If you would like to be on Podcast written by a software engineer, reach out to us. Just email contactaradsu.com can't wait to have you on the show. Once again, thank you so much for listening to podcast written by software engineer. Don't forget to hit the follow button on your podcast app and leave us a review on Spotify and Apple podcasts. It's completely free and if you want to tell your friends about Podcast spooned by a software engineer, that's totally cool as well. Anyways, I'm parentsu and you've been listening to podcast brewed by a software engineer.