Kshitij: Hey everyone. I'm Kshitij, co-founder and CTO here at Orb. I'm super excited to be joined by Julianna today. Julianna is the co-founder and CTO at Stytch, which is an all-in-one platform for authentication and identity management. Stytch has had a lot of success over the past few years, so I'm super excited to dig in with Julianna today.

Julianna, welcome.

Julianna: Awesome. Thanks so much for having me.

Kshitij: Yeah, so maybe just to get started, tell me a little bit about your background and how you got to where you are today. Just maybe give me the Stytch Company origin story, but also any of your personal story getting to this point.

Julianna: Sweet. So I studied computer science at Stanford, and I think that's when I first started to get interested in kind of like startup scene.

It's where I discovered computer science, too. I didn't really know what that was before I got there. And I think started to sort of navigate sort of the startup scene there and thinking about maybe what I wanted to do after graduation. And I really gravitated towards startups. So I interned at a five-person seed-stage security company doing engineering.

And then when I graduated, I joined Strava. I am really big into running, do triathlons. And so Strava was like the dream job, like fun startup in San Francisco. I used it every day. And I did growth engineering there, which was a lot of fun to see how consumer companies think about onboarding, retention, all of those things.

I then joined Plaid in 2017 on their backend team, and that's where my co-founder, Reed, and I met. And while I was at Plaid, I worked a lot on projects related to fraud and authentication. So working on sort of their first fraud engine that was identifying and blocking credential stuffing and account takeover attacks.

So what, happened is a random website gets hacked, usernames and passwords are stolen, people reuse the same password across many of their different online accounts. And so, we would see this pass-through fraud to the banks, people trying to see if those stolen passwords could get them access to a bank account at 10,000 banks that we integrated with.

And something we, saw there is that a lot of these attacks would be focused on banks that didn't really have strong two-factor authentication because you can get a lot more access with just a password. And so we ended up building out our own two factor at Plaid to help protect those accounts and layer on top of a bank's username password flow. And so when we went to go and do that and at this point, Reid was the PM for this team.

We looked at different vendors for authentication. We were like, surely there's like some out-of-the-box plug and play API that's really flexible, easy to integrate. It will work within our product constraints but do the heavy lifting when it comes to building out these one time passcode flows.

And basically didn't find that. And so we ended up building that in-house. Wrapping things like Twilio, et cetera, and just yeah, building from scratch. I then joined another company called Very Good Security as one of their first product hires. And while I was there, I worked on ripping out Auth0 and replacing it with an in-house solution.

And the reason for that was lack of flexibility from the Auth0 product and really wanting to be able to build the experiences that we were trying to build. And so Reid and I were catching up after I'd left Plaid and he was still working on building out some of this authentication there.

And we were like, this is wild. We're now building auth in house at two different companies. Yeah. Auth0 is like the big incumbent in this space. They've done a lot of things right, but they're not like the modern API-first developer tool that we would expect. And so we then spent basically six months trying to convince ourselves that we should like actually quit our jobs and go start a company.

We ended up starting the company in June 2020. So there was like in the background, COVID was happening and this is really an uncertain time to be taking this leap of faith. But we just kept hearing over and over again from talking to people that they were frustrated with whatever they were doing for authentication.

And that the way we were sort of approaching this problem was really interesting. And so I think we just felt this momentum of people getting really excited about the idea and we were excited about it and we're like, okay, we should just go do this, it feels like there's a really big gap in the market.

And yeah, started the company in June of 2020.

Kshitij: Congrats. It sounds like what, three years now. And I know that lots of folks use Stytch or were happy users of Stytch. So it's exciting to hear that, that come together. And I certainly take comfort in the fact that you're a CTO of Stytch that comes from a company called Very Good Security, so that sounds like a good place to be.

I want to talk a lot about the technical challenges in building a product like Stytch. Before we get into that, I want to start with something a little less technical, which is Stytch is pretty famous for having ads all across SF, I think a while ago now, on buses and billboards, so tell me a little bit about that story. Whose idea was it? How did that come to be?

Julianna: Yeah I don't actually remember if it was like Reid or me that came up with this idea, but the two of us were talking about how do we really establish our brand because Auth0 has a really strong brand. And so,one of our best performing like keyword searches on Google is like Auth0 alternative.

And so how do we like go from being this tool that you discover when you're like looking for Auth0 alternatives to being something that's like said in the same breath as Auth0 of "Oh, we need to build authentication." Look at Stytch, look at Auth0 and build that brand awareness. And just knowing that the people that we're selling to engineers are our core ICP.

We're in San Francisco. There's a big concentration of startups and engineers in San Francisco. And so it's a really good place, actually, to do a campaign like that for a developer tool. I remember sending it to my mom, like, when we did it. And she's like "Wait, you don't sell to consumers. Like, why are you doing this?" And I was like, "No, engineers are all over San Francisco. She's like, "Oh, okay, that makes sense."

And so it was really meant to plant our flag and really establish that sort of like grand awareness of who we are and that we're something that you should be looking at if you need to build authentication.

So we did it, I think like last spring. So it's been maybe like a year and a half or so. We're starting to talk about whether we maybe do something again like that. I think we've expanded our product set quite a bit. We do so many more things now and want to get that word out there too.

And I think it has been, it's been super effective. The number of people that bring it up and talk about it is still really high even like a year and a half later. And so I think we, we found it to be super effective. And trying to think about whether something makes sense again, soon, because there's a lot more to talk about now.

Kshitij: Yeah, that makes sense. And I know you all talk about yourselves as this identity managed platform. And I think those ads, a lot of them were centered around passwords or passwordless authentication and login flows. So maybe to dig into how that product surface area has expanded, let's talk a little bit about the technical problems that you and your team at Stytch are solving, and how would you categorize those and how do they relate to product surface area that you're building towards?

Julianna: Yeah, definitely. So we started out as a passwordless company, and the reason for that is a lot of that experience of kind of seeing the pain points both from a user conversion standpoint, but then also from a security standpoint of typical password based authentication where people are reusing the same password and leaving their accounts wide open because that password gets compromised one place and then it's all over. And so we started out as passwordless because we were like, okay, from both a security standpoint and a user experience standpoint, we think this really is like the future.

We ended up building out password support right after we did the big billboard campaign that was all passwordless. And the reason for that is that we found that a lot of people were, like, interested in moving passwordless, but it didn't feel like we were at the right point in time to go 100 percent passwordless.

And so we see a lot of companies that use us integrating multiple different options, and passwords will be one of them. We tend to see consumer preferences really heavily skewed towards things like email magic links or OAuth logins but there's often a sort of minority of users that are really set in their ways.

They love passwords. And so having that option was really important. But we still think about it from a kind of security perspective and user experience perspective. I think that's really intertwined in how we build our products, trying to make sure that we have good guardrails so that you can't shoot yourself in the foot when you're building authentication with us.

Or if you're an end user, you're using a company that uses us for auth but also trying to make sure that user experience is really smooth, keep an eye on things like conversion and making sure that people are actually able to log in. And so an example with passwords is we do a check to the have I been pwned database to see if a password has been breached when someone's creating a new password.

So we help prevent those attack vectors. And so I think even though we do passwords today, like I think that original ethos of kind of both security and user experience being the two main pillars holds true in terms of what we're doing today. We've also expanded even further than that into doing fraud detection and prevention.

And so we have a few different things here. I think most exciting one so far has been a device fingerprinting product that helps to identify traffic basically the moment it lands on your site. So now we can help prevent bot attacks, prevent account takeover attacks, also recognize users, so if you want to build a more sort of like custom returning user experience you can recognize those returning users. And so I think we're continuing to expand. Auth is not just like a login box is how we think about it. How do we have that more holistic view of who your user is to really help improve, again, security and user experience across the board.

Kshitij: Yeah, so one of the challenges I imagine building a product like this is, of course, Stytch has a bunch of SDKs and a lot of integrations. In general, you're just playing in a lot of different environments, right? Different networks, I'm sure some company private networks, but also across all these different browsers.

And so how do you think about that as a technical problem? I can just imagine that you could spend, days, if not weeks and months, just chasing down people saying, "Hey, this thing didn't work," and you don't know if that's because there's a bug in the Stytch platform, whether there's something about their network environment or just could be something totally local to their computer, right?

Julianna: Yeah, definitely. It's a really hard problem. We see it with integrations we also see it with things like email deliverability. And so there's like long tail of chasing down every single edge case. I think we definitely go much further than you would if you were just a consumer company or a B2B company just serving your end users because we're serving so many different use cases and so something that shows up today is maybe a small issue on a certain browser is something often to pay attention to because that might increase as that browser gets more popular. Or I think there's this trend towards more privacy centric browsers and settings and whatnot which end up having pretty big implications for things like session cookies and lifecycle of sessions and all of that. And so we try and go pretty deep on all of those things to really understand and I think get to a good answer about whether this is something that we can improve upon or also knowing that if you're choosing to have the most intense privacy controls on your browser, you're also probably signing up for a slightly worse experience on the web, and so, we're maybe not going to go and engineer some extremely specific solution, but making sure that generalizably, Stytch is usable and functional on a wide variety of different platforms and browsers and in different sort of like email security settings. For example, we've gone really deep on on making sure that those magic links or password reset emails are able to land in users' primary inboxes and I think it's like making sure that we hold ourselves accountable to understanding those different situations and knowing that we're not going to be able to fix every single sort of edge case, but understanding if there are things that are generalizable that we can solve and probably going further to solve those edge cases than most companies would.

Kshitij: Yeah, that makes sense. And I've seen in previous jobs where you'll send a password recent email, but the email client will automatically click that link for you, right? And then if that expires or it's a one time link, then you get into all these sorts of weird loops where someone can never reset their password.

I'm sure that's maybe just the tip of the iceberg that you've seen. But like, how do you structure things like very tactically, like on call rotations for that? Is that something where, you know, as an engineering leader, you have to figure out how are you going to budget engineering time and what people are looking into. Is that something that's kind of a judgment call? Do you try to build a framework around how generalizable is this problem? Is there like thresholds for, has this affected this many users or this many sessions? How does that work?

Julianna: Yeah, that's a really good question. So the way that we do our on call is basically we do week by week, so an engineer will be on call for seven days, and during that week, the expectation is that they're not working on any core project work, and they're just working on call things.

If there's nothing that's coming up, working on things like more like metrics and monitoring or fine tuning alerts and all of that and like picking up bug fixes in the backlog, for example. I think that definitely ends up being for the most part, a pretty solid budget where we have room to actually go and chase down some of these things and at least triage them as they're coming in.

I think we're probably fairly sensitive about what we treat as an incident. And there's actually an issue a couple weeks ago with one of our password reset emails. It would land in the inbox, but it was getting flagged as like a spam message. It wasn't actually going to like potentially dangerous, And so it was getting flagged. And so I think that's a really good example of like, to us, that's a broken product, because that email should be landing in your inbox. And so the engineer that was on call, took this on as an incident of emails are not being delivered how they should be.

We need to get to the root cause of this and solve it. And ended up being some tweaks in the CSS in our email that ended up solving it. And it used to work and Gmail changed something and this was only affecting Gmail, but that's huge percentage of our traffic. And so I don't think we have a perfect science of figuring out what is the threshold of users impacted, I think generally it does need to be like material number of users and generally reproducible.

I think sometimes we'll end up in situations where we get a report from someone that one user is reporting this thing, and they can't reproduce it, we can't reproduce it, and those, I think we're pretty good at just saying, okay we need to be able to reproduce this, and once we can, then it's probably worth chasing down.

But I think that's something that we can definitely get better at over time is kind of identifying those thresholds. But I think something that we see often is that sometimes something will start as a smaller problem and then it'll increase because maybe it's like a new version of Chrome where something's happening, right?

As more people are upgrading, then you see more people and even though things like might be small numbers, we tend to like try and figure out root cause and at least triage and decide if there's something that we can and should do but yeah, probably needs to get more scientific over time.

Kshitij: It sounds like the thing that's tricky in that is you don't have very solid contracts with the other players in the ecosystem that you interact with, right? You're saying like, oh, Gmail changed something about their algorithm for detecting what's a dangerous email, or Chrome maybe just changed something about how they do session management or storage on the browser.

And that feels like not a place where you can very predictably or reliably say this is going to turn into a big deal over time, right? So, yeah, kind of on that topic. One of the things that you do is as CTO right, is you're representing to customers and prospects that problems won't happen or Stytch will do right by them when they do happen.

So what is your strategy for gaining customer confidence on day one or during a sales cycle? And I know that you all have a community Slack channel. So even in the interactions there, how do you go about inspiring confidence, especially when someone might be migrating from a solution like Odds Zero or Octa?

Whether or not those platforms have problems, just bigger names to begin with, right?

Julianna: Yeah, it's definitely a question that comes up a lot in larger deals. It's what is the reliability story here and we'll definitely sign SLAs with those bigger enterprise contracts. And I think it's about telling the story of how we think about reliability and how we think about building our infrastructure to be resilient.

I think it's also about being transparent that we're never going to be a hundred percent uptime and maybe that's something that we can strive for but, that's pretty unachievable in the long run. And knowing that we're going to try and get as many nines as we can.

And that's the standard that we hold ourselves to. And then also I think having really good handling of like incidents when they do happen. Bug reports when they do happen and taking those really seriously. I think that's where we're able to build a lot of confidence with customers.

Whether that be someone like reporting maybe they're integrating and there's like a bug in one of our client libraries or something like that, that's making sure that we like jump on that and like, "Yeah, this is broken. We're going to fix this." And not sweeping bugs under the rug or not responding appropriately.

So I think that response is really important. I think it's similar for postmortems so depending on what the incident situation is the impact of it, if it's a total outage or something smaller, sometimes we'll publish a public postmortem. For other incidents we'll often just send the postmortem to affected customers. Takes a lot of time to put together a really good public postmortem, but we found it builds a lot of trust.

And so I think we've, we found a lot of value in that of making it clear that we have extremely high standards for our own reliability being very willing to sign SLAs and then also illustrating that we practice what we preach and actually having really good incident response or response to bug reports and all of that.

Kshitij: Yeah, that's interesting. I think one of the things that I've thought a lot about on the Orb side is how do you minimize the kind of critical path surface area of the product, right? Where it's like tricky to do in something like, billing or it's like, okay, data ingestion, you can't really be down usage analytics, you can't really be down. Obviously, you can't make mistakes on the payment stuff. And I feel like it's similar at Stytch where the core kind of login experience is super critical, but also even the admin and auditability experience, all the SDKs, it feels hard to scope things out and say, okay, this stuff, maybe we can cut a little bit of slack on and this other stuff has to be super airtight, right?

It really does feel like a very large percent of the product surface area is something that people rely on, right? Are there any other fun, like downtime incidents that you recall? I know you just talked about one, but anything where maybe you had to make some deeper changes in your stack?

Julianna: Yeah, that's a really good question. I don't know that there's been anything that has resulted in a really major overhaul. I think we are really fortunate that we likewent slow in the beginning to like build a lot of our infrastructure to be able to handle scale, which I think at times when we were just getting started is are we really sending like this much time on just building the foundation?

I think that's ended up being really valuable as we've gone to scale. I think there are definitely projects to improve, different things or tweak, different pieces that have come out of incidents. I don't think we did like monitoring and alerting very well in the very early days.

And I think there were like a few incidents two plus years ago where customers were like reporting them and, I, or Reid or someone else on the team would be like on the website and realize it was broken. I think one of the great things about our product is that we can also dog food it.

And that's a really good experience just from feeling our own pain if we're creating it for ourselves. And so I think we invested quite early on as a result in pretty comprehensive alerts and monitoring, and I think now are on the opposite side, where we have a lot of alerts that are low urgency alerts that just go to a Slack channel, and sometimes they're a little bit noisy and non actionable but oftentimes they are, and I think it's really good for us to be overly sensitive to those types of alerts and just over correct, I think. So I think that's one interesting example of I think lucky that we learned that lesson really early on before we really had that many customers.

And so, we were able to course correct and I think over-correction has actually been really valuable there.

Kshitij: Yeah I remember maybe a few days ago we broke redirects for a small subset of customers and Reid messaged us with " Hey, we saw this anomaly alert come in. Maybe you all like changed some wiring of your redirects. Something you should look into."

I was surprised. I'm like well, that's fairly sensitive. And, I think reliability is one thing, there's also the security aspect of it, which obviously you're building an authentication company, you have to think about that from day one. What sort of processes did you build into place to help with that?

And obviously you're hiring engineers that may not have worked on security products before may not have end-to-end understanding of what it takes to review security-sensitive code, for example. So is that something where you contracted it out and hired a firm? Did you add a bunch of CICD process? How did that work?

Julianna: The main thing that we've done is we work with a firm called Latacora. They're basically security engineering consultants. I think they maybe have 30, 40 people on staff. So it's quite large. They have a bunch of different sort of like experts, right?

They have AppSec, Infra, all of that. And depending on what situation we're facing there's someone that we can go to that's going to be an expert in that space. So it's getting like fractional security engineering resources. We did that really early on. We'd worked with them at Plaid and so we knew them from that experience.

And like when we started the company, basically I reached out to them and I was like, "Hey, we're starting this company. Security is going to be really important. Can we work with you guys?" And they were like, "You barely have an engineering team, like we're going to create all of this work for your team or like they're not going to create enough work for us. You don't even have a product. Build something and then and hire a little bit more of a team and then come to us."

And so we still ended up like starting to work with them. I think much earlier than the average company that they work with. And the reason for that is we are a security company. And I think they care a lot about authentication as well. And they see this across all of their other customers.

And so it's been a really valuable relationship because they're able to give us product feedback, how should our session management product work, for example. What's the right balance between doing something like session tokens versus JWTs and how you think about that.

So they're in there reviewing our specs. They're in our GitHub, they're in our Slack. So I think baking them into the engineering culture, I think has been a really effective way of training our engineers to ask questions because they're so accessible that you can ask questions. even if you're unsure if it's actually something worth like getting a security perspective on. I think we get people to like index on asking those questions and that helps train everyone and helps really create that culture of going slow whenever it is something that could impact security and really taking the time to understand what the right solution

is.

Kshitij: Interesting. So it sounds like then as an engineer at Stytch, you have to have, of course, a framework for, what general areas of the code base are security sensitive, what sort of changes do you need to get review on, but then it sounds like, I can put up a PR and tag someone at this firm who can come in and say, oh, here's how we should restructure this, or yeah, this looks good, or maybe even this part isn't actually that security sensitive, just go for it.

Is that right? Is it that up close to the code base itself?

Julianna: Yeah, it is. I would say that oftentimes we're getting feedback before code reviews on most things. We do get code reviews from them. They look at our code. Sometimes they'll look at our code, even when we're like not shipping something new, like they'll do ongoing checks and things do not often get flagged, but sometimes they're like, oh walk me through like how this sort of new thing that you've introduced maybe interacts with this other thing and so they're able to give that sort of granular code level feedback because they're also now very familiar with our code base. Yeah. They've been in it since the beginning, basically.

Kshitij: Yeah. And like you were saying, in some sense, they're not just security researchers, but in some way they are also consumers of the product. I'm sure they've worked at companies that have had to build some of the stuff themselves and really understand the ins and outs of the product flows, not just the specific security feature that you happen to be working on.

So I know that Stytch also has a pretty strong culture around documentation. I've seen you talk about that publicly around building some of your own documentation experience. And I think it makes a lot of sense when you're in this context of hundreds of SDKs and different environments, really trying to get people to onboard onto the platform as quickly as possible.

And while doing that, getting them to slow down enough to understand the core concepts, right? Because I feel especially in security software, there's this tension where you can get someone up and running with a single line of code, but then if they're doing the wrong thing for their application model, or they're not really understanding what guarantees they're getting out of the specific flavor of OAuth flow, that seems bad, too.

How do you think about documentation? And maybe more broadly, how do you think about documentation as a tool for onboarding people onto security as a field of expertise or as an area of knowledge for any engineer?

Julianna: Yeah, definitely. I think we have really prioritized documentation just from the beginning.

I think some of that is because we were started during COVID everyone was remote when we first started. And so even as an engineering team of five, writing down what people were working on and writing good specs was really important. I think we also were fortunate to hire some early engineers that really enjoy writing technical specs.

And so we have, I think both a really good internal documentation culture, but also external. And I think they're related in a lot of ways. I definitely would not say we're perfect with internal documentation, but I think I'm pretty continuously impressed at the quality of and rigor of the specs that we're writingthat I think that becomes really valuable for people onboarding or if you're building a new product and you're trying to figure out, like, why did we do this thing with this other product. There's a really good repository.

It's not kept up to date maybe that would be, like, the perfect gold standard, but I think the level of detail there is pretty good. The other thing that we did from day one, basically, was have engineers write our external documentation. We didn't have anyone else to do it. It was Reid, me, and some engineers and basically made sense for them to write it. But I also think that we did some things intentionally to really build a strong culture around how we think about docs. So one thing that we did from the beginning is write our external docs before we built the product. So we would put on our website like "coming soon" for this new auth product and we'd write the API documentation. Once we did the tech spec, that would be the next step. And then you'd go and implement. And so I think that helps to get people in the habit of thinking about how the product will actually be used. How will external people like understand and helps catch, too, if there's something that you're doing, that's not super intuitive in terms of like API design or how different endpoints work together. I feel like that can often be more obvious when you see it in docs than if you're just writing the code. Yeah. So I think that's been really valuable.

I think something that we are good at today but could be better at is actually explaining why we do certain things, particularly from a security perspective. There's some things that people will ask questions about, like there's something we do where you can only have one unverified factor on a user at any point in time to prevent things like email or phone number squatting that can lead to account takeover vectors.

And we have these stringent rules in place to help protect accounts. I think we're getting better at this and starting to talk about it more, , actually articulating that so that it's not something that support is getting aabout "Heyt hey, I want to do this thingthing."We have to go and be like, okay. but like here's why you don't actually want to do that. I think we're good at going into detail about how different products should work together in our docs because I do think that's something that can be hard for people trying to integrate with us maybe to know off the bat. Like the security best practices about how to actually integrate Stytch. So we try and document anything that maybe is like a trade off that people have to decide to make about long lived sessions or something like that.

But we also try and just bake as much into the product as possible so that we don't even have to educate you about that. But then the piece that requires education is the like hey, you can't do this thing because it's not good.

Kshitij: And that's actually a really interesting point. How do you think about the trade off between being opinionated versus giving your users the optionality to take potentially unwise amounts of security risk. So I'll give you an example I can think of at the top of my head. If you're generating like a JSON web token, you can put in whatever expiration you want in that. And obviously that I think increases the amount of time where credentials could be compromised but this token is still valid. And to some extent that feels like an organizational decision of "Hey, this is our product. This is how how important it is for a session to be immediately locked down when something happens. But I also imagine Stytch wants you to fall into the pit of success, so to speak, right? And not shoot yourself in the foot. So how do you think about that?

Julianna: Yeah it's a really good question and something we like talk a lot about because I think for the like variety of customers we have, there are some things that are like going to be fine for a certain customer and not so fine for another customer.

And it's kind of like up to them to figure out like that risk calculus. So for example somethingwhere there's like sensitive customer data, you're probably going to want to have that session pretty locked down. But you can imagine something that's like an online magazine that uses us and there's just not that much sensitive data that you can get from that account and being able to have a long lived session there so that you're not having to constantly log back in is really important. And we try and be flexible to the point that makes sense and not go beyond that.

But also try and provide the right information to people to make those informed decisions for themselves. I think that's something that I think like we can always get better at and something that we do talk about as we're thinking about some of these product limitations or how we think about that flexibility.

Because I think it's one of the value propositions, is that you can build the experience that makes sense for you with us, but if you don't know what makes sense for you, that can be a double-edged sword.

Kshitij: Yeah, and ultimately it feels like there's some liability on you if something goes wrong and even if people have just misconfigured something, they can come to you and be like, "Hey, Stytch didn't work the way that I had thought," which seems like a tricky situation to be in at that point, right? So maybe the last question to wrap up here, and I'm sure you've thought a lot about this starting the company and over the years, do you think authentication is a boring problem?

And I say that from a background where I work on billing and pricing. And so, maybe let me ask it this way. If I were an engineer and you really wanted to recruit me and I was an engineer applying to Stytch, how would you pitch working on engineering at Stytch?

Julianna: Yeah, so I think one of the things that gets me really excited about what we're building is just the impact potential of it. So I think there's a lot of impact for the engineering teams that we're selling to, the companies that are using us. But I also think there's a lot of end user impact. Everyone has frustrating login experiences probably once a week and our vision is really to solve that, to make logging in on the internet really seamless and easy for those good users and to have extremely hard protections against bad users taking over your account, but be intelligent in how we do that we can eliminate a lot of friction for good users out there on the internet.

And so I think that problem is really resonant. I think it's something that, I don't know, like some of the other companies I worked at, like trying to explain to my mom the data security infrastructure that Very Good Security was doing. She was like, that's cool. I don't know what you're talking about. But like being able to explain, Hey, like that password reset that you don't get that email for, or like, you're always getting logged out of this account or whatever it is, that's what we're solving. I think that's pretty exciting for people. So I think just knowing the impact potential is the main thing.

I think there also are really interesting technical problems that we're solving. I think the reliability piece is actually a really fun and challenging problem because you have to figure out how to build really resilient and scalable systems.

And, like we were talking about earlier, do so in a way that can be integrated and used in essentially infinite different combinations. I think the other thing that's a really interesting sort of challenge is a lot of this fraud detection stuff of how do you really, with a high sort of degree of accuracy, identify bots versus humans.

Because I think that's a really key sort of piece of being able to realize that other goal of making login really frictionless.

Kshitij: Yeah, that makes a lot of sense. In some sense it is reframing the problem to building this foundational infrastructure for the internet, right?

Whether it's this seemingly simple login box, but especially what you're talking about at the end there, really trying to understand the nature of internet traffic seems like anything but a boring problem, right? Thanks, Julianna. I appreciate your time. And that was a really fun conversation, so thanks for joining.

If you want to learn more about Stytch Stytch is at s t y t c h.com. And thanks again, Julianna, for joining.

Julianna: Thanks for having me. That was a great conversation.