In this episode, we talk to Julianna Lamb, co-founder and CTO of Stych, about building a password-free world. Every password that you can remember can be compromised.
Every password can be compromised. Stych helps companies build authentication flows that don't need user passwords.
Julianna grew up in Idaho, where she didn't even know what computer science was. After stints as a software engineer and product manager, she found a role where could figure out what the organization should be building: CTO and founder.
Their first product was email magic links, which is more complicated than you think. Most importantly, how do you always avoid the spam folder? Copy changes in an email can make all the difference.
Developer tooling is undergoing a renaissance now that smaller companies are getting into the game with API offerings. The big thing that differentiates good tools from bad is easy to understand documentation.
The right metaphor for API services isn't SaaS, it's eCommerce. Plug it in into your app without giving up design and user experience.
Julianna Lamb We see a lot of people adopting email magic links either as like the sort of primary form of authentication, or some people like the Instagram example, they push you to an email magic link flow instead of doing a password reset now. And so that was sort of like the first product we built, because we think it can stand alone as an authentication factor. It's decently complex to figure out how to build and on the surface, sometimes you might be like, oh, it's just like a token, just got to verify the token. But figuring out things like email deliverability, making sure that's always showing up on the top of a user's inbox, making sure you have like all of the right sort of security constraints in place. There's a lot of complexity under the hood.
[intro music]
Ben Popper Big Tech has advantages in budget and resources when it comes to building powerful infra, right? With CockroachDB, you can now build on top of that! The founders came from Google and basically built open source Spanner - but with a serverless option you can use for free at cockroachlabs.com/stackoverflow!
BP Hello, everybody! Welcome to the Stack Overflow Podcast. Hi, Cassidy. How are you?
Cassidy Williams I'm good! I'm so excited to talk to Julianna today!
BP I know, we have a great guest today. We're going to be talking a bit about passwords, we are going to talk a little bit API's. We're gonna be talking with Juliana Lam, the co-founder and CTO of Stytch, a startup that is all about the rise of cool API's. It's like cool jazz. It's like a genre of API, like the Miles Davis of API's.
CW Yeah, technically, we're not even talking about passwords. We're talking about password-lesss.
BP Yeah, forget passwords. I don't even want to deal with them anymore.
CW Yeah, ugh. The past. Julianna, welcome to the show.
JL Thanks so much for having me. It's great to be here.
BP So for folks who don't know, give them a little background. Yeah, how did you get into this area, computer science, software engineering, How'd you end up as a co-founder and CTO?
JL I'll give a quick sort of background, and then in a bit more detail of sort of how we landed on Stytch. So I think if you told me in high school, that I would be a CTO, I probably would have laughed in your face. I don't think I knew what computer science was. I grew up in Idaho. There were not many software engineers walking around there. And I really liked math growing up. And so I sort of like stumbled upon computer science in college. And I'm super grateful for that opportunity. And started my career as a software engineer. I worked at Strava, and Plaid, and then spend some time as a product manager at a company called Very Good Security. And at Plaid and BGS. I ran into issues building authentication, I worked with my co founder Reed at Plaid. And he also worked on authentication at Plaid. And so we basically, were super frustrated with the tooling out there to build user auth, we felt like there wasn't a super developer friendly solution on the market. And we sort of saw this trend of password-lesss, really starting to pick up steam, both from like a security perspective with reuse of passwords and sort of account takeover attacks, but also from a user experience perspective, starting to see really interesting companies like CashApp and Instagram start to build passwordless flows. So we started Stytch to make that easy for other people to do.
BP Yeah, I actually just had a conversation recently, with my mood from Very Good Security, seems like a company that's on the up and up. So what was that transition for you like from engineering, to more product management to more almost like, you know, deciding to start your own thing?
JL Yeah. So I think I always really enjoyed sort of figuring out what we should be building as an engineer. And I spent a little bit of time at Plaid as well doing solutions engineering. So spending time with Plaid's customers trying to understand like how they were using the product, etc. And from that experience, I felt like I wanted to get a little bit more back in sort of the building mode. And so product felt like a really good sort of combination of the two, getting to spend some time sort of figuring out, you know, what it is we're building, but then also sort of being boots on the ground, and actually building those things. So that was a really interesting experience. I think all of those has set me up really well to be a co-founder and CTO, I think, I have the technical background, but I also have spent time sort of thinking about sales and thinking about product. And so my day to day now is mostly sort of like engineering management, providing, you know, feedback on specs, etc. But then a lot of it is product as well. I feel like and a lot of ways this is sort of like the perfect role. It's all those things that I was trying to get with those other roles, sort of all grouped into one.
CW How is Stytch so far? You have raised money, you have a team going. How big is the team? How's it going so far?
JL Yeah, so we're a little over a year. And at this point, we've raised a seed and series A and grown the team to a little over 20 people. Number 20 and 21 started this week. So super exciting. A year ago, it was me and Reid. So we've come a long way and that year and have shipped a couple different products. And there's many more that are on the way very soon. So it's been super exciting to sort of, you know, go from an idea a year ago to like multiple products in market, customers live using us. A big focus that we've had, as well as like building a really great self serve flow out of the gate. And so it's pretty cool to just see we have like a signups channel on Slack and like, just see random people signing up. And it's like, how did you find us? Where did you come from? This is so cool that like, you want Stytch!
BP So what were some of the first products that you brought to market? Like what were those initial problems you wanted to solve? And talk us through a little bit of, yeah, sort of like the approach in terms of the technology or the software?
JL Yeah, so the first product that we started with was email magic links. So making it really easy for you to drop in either with a sort of front end prebuilt SDK, or direct API integration. Email magic links, we see that as a really great sort of password, username password flow alternative, if you think of most password reset flows, they end up just being an email verification with like five extra steps tacked on top to actually get you into your account. And so we see a lot of people adopting email magic links, either as like the sort of primary form of authentication, or some people like the Instagram example, they push you to an email magic link flow instead of doing a password reset now. And so that was sort of like the first product we built because we think it can stand alone as an authentication factor. It's decently complex to figure out how to build. I think, on the surface, sometimes you might be like, oh, it's just like a token, just got to verify the token, but figuring out things like email deliverability, making sure that's always showing up on the top of a user's inbox, making sure you have like all of the right sort of security constraints in place. There's a lot of complexity under the hood.
BP I am curious, how do you make sure it's not it shows up at the top of my inbox and doesn't get caught in a spam folder or buried by other mail? Like, how does my inbox know this is something worth showing it to me?
JL Yes, that is a great question. It's something we think about, like constantly. I was talking to Reid this morning about this as well. I don't think it's a solved problem, I think it's something you kind of always have to be like, paying attention to some things that are important are around like IP reputation, making sure your domain also has a solid reputation, and that they're like growing somewhat naturally. So you don't want to just like all of a sudden jump to like super high traffic, because that looks like spam, we spent a lot of time AV testing sort of tweaking copy in the email as well. And like really simple copy changes to a subject, for example, can make a huge difference between the promotions tab in Gmail and like the primary tab. So there's a lot of sort of factors. And I think it's an ongoing thing of like just sort of seeing what's happening and making sure we're fine tuning it.
BP That's awesome. I thought maybe there'll be a technical solution. But, right, here, you're trying to understand the filters and working on the copy. That's what we struggle with in marketing all the time. So if you have any tips and tricks, I'll take them after this call is over. So another thing you mentioned, that I sort of wanted to dig into was, you know, this idea that passwords may not even be for the consumer themselves, you know, like necessarily always the most secure or the most, you know, useful sort of flow. So like, when exactly I forget my password, and you're sending me down email magic link, embedded in that is like this idea that like it's not worth resetting it and changing it, you know, if you can verify it in the same way you would verify anyway, why drag me? But then what about my old password or a compromised password, then it's on me to like go in and change it and update it? Or what's on the user there? Like you make the user experience easier. But what's left one the user to like, want to continue to have a sort of safe journey after that?
JL Yeah. So what we think is ideal is that you just get rid of passwords entirely. And the reason for that is you touched on it, compromised passwords, right? So we all including me, who like thinks about this all day, every day, reuse passwords across many different online accounts. And so one of those accounts gets breached, right, and then all of your other accounts that use that same password are super vulnerable. And so we are sort of pro going password-lessfor that sort of primary security concern of you leave just like massive doors open when you trust users to use complex and different passwords across all of their different accounts. So we would advocate just sort of replacing the password with an email magic link. I think there's ways that you can start to push people towards those password-less flows. So maybe is just giving them the option to like get rid of their password when they like go down that magic link flow. Maybe it is sort of slowly migrating people over or you can still like keep that password flow if you feel like there's some reason to do so.
BP Cassidy, what do you think? I mean, in my mind I don't know the answer to this question today. And I'm sure you've studied it, but like, what's at a higher risk that my password is going to be compromised somewhere that I reuse it? Or that, right, somebody is going to get ahold of a device of mine and from my email to do it seems like that the former far more than the ladder? My devices already protected now by biometric and all these other things. So yeah, it seems like if you want to minimize the attack surface. But go ahead Cassidy.
CW Oh, well, it's kind of like what you said, like minimizing the attack surface is great. Unfortunately, I think most security issues that you see with passwords and stuff is people reusing their passwords for their email, as well as for other services. And so if they end up getting it from another service, they get into your email, you have an issue, right? But if you can keep your email secure, then there you go. And I'm sure there's plenty of people trying to solve that problem as well.
BP Right. And Julianna, where do you sit? Yeah, I mean, like, could we go to magic links, and biometric and that would be enough, like, like biometric is really the simplest and safest as far as I can tell. But it's not available to everybody on every device is the issue?
JL Yeah, definitely. We think that it's not like a one size fits all solution when it comes to password-less. And so that's why we're really focused on sort of building out this platform giving you different options. So a bit depending on like your use case, type of data you're using, where people are accessing your application, at demographics, all of those can sort of skew like what might make the most sense. And so I love biometrics, I think that's fantastic. But you do run into problems, right? If you have desktop, and mobile, you can't like sort of really cleanly tie biometrics across those can't count on everybody having, you know, a new Mac with a touch ID to be able to even do biometrics on web. And so we see these as sort of like the building blocks that help you build flows that can be flexible, they can work for your users, and maybe give you options to where you can like sort of lean on, say biometrics heavily on mobile, but then when you go to desktop, maybe you have like the email magic link flow, or something like that as the option there.
BP So I'm gonna throw this over to Cassie. But just to sort of introduce the topic, you know, Stytch is, starting out with sort of a thesis about what will make it a successful company and easy for people to build around your ecosystem. And that is make something that has sort of modular building blocks and a great API a great API experience. Cassidy, I know you probably think about this as well. So you're coming from like the developer experience, you know, side of things to think of how to build the ecosystem at Netlify. So what makes a cool API? Like, I'm the OK Boomer guy here, but like, what makes a cool, a cool API? What are people looking for? You know, what are the trends that we're seeing shaped sort of that ecosystem?
CW I feel like developer tools in general are seeing such a rise up because people are realizing we can have better than what we have now. Developer tools have, for a very long time been owned by a lot of very large companies that because they have basically a monopoly on the market, their user experience, their developer experiences, not ideal. I'm trying to be as kind as possible here. And so it's a very exciting time to be an API company. And I'm sure Julianna, you have seen that and more with Stytch and with other companies around you.
JL Yeah, definitely. I think one sort of thing we think about with building our product is equating it more like an eCommerce company than like a SaaS company. Because you should be able to like come to our website, as a developer and like, buy our API. And it should be really easy to understand really quick to get up and running, you should be able to sort of do everything without talking to a human and spend as little time as possible on that experience. And I think if you sort of, yeah, look at more legacy developer tools, it's all of the like, contact sales request a demo, and like, as a developer, you just want to like build it and get it working. And so we focus a lot on that sort of, like initial integration, understanding of how this works, how it fits within your application.
CW I love that angle a ton thinking of it as e commerce instead of SaaS, because it is different types of customers that approach it. And it's like dev commerce, I'm sure there's good some kind of name you could coin for this in a blog post, and you'll be a thought leader.
BP And so in that model, does that change the business model at all? Is it more like transactional one time? Or it's still you're just sort of saying like, we want you to walk in, pick something off the shelf and get using it now. But then you're going to have that traditional like, you know, model of the number of times you use this API will eventually rate up to how much you spend with us?
JL Yeah, that's exactly right. We sort of base our pricing on like a monthly active user metric. So the more monthly active users you have with us, the more you pay us, we do still have Like contact sales if you'd like to negotiate a contract, but you can like put a credit card in and just sort of pay for what you use. So we still have that sort of recurring business model, though.
BP And so yeah, if you had to sort of highlight anything that you feel like really differentiates you, or the things that you feel like, Yeah, it really sort of give developers joy or make them want to use your API, what would you point to? Like are there specific hooks or specific, you know, approaches to the way you design it that you think are important?
JL Yeah, I think there's two things here. One is more around just like the developer experience, we get a lot of compliments on our Docs, we spend a lot of time on them as well.
CW So huge!
JL And just making them feel like, you know, as a developer, authentication can be scary, making that field welcoming. And like you can understand what we're doing. We've heard that like, other companies make people feel dumb, because they like can't understand the Docs. And so they don't know what to do. So focusing on like, the design the UX of those Docs, so that they're very approachable and easy to understand. And then I think the other big differentiator for us is that we're really leaning into sort of like the API first and building blocks versus trying to have like, a one size fits all solution that maybe it's faster to integrate on the front end, you know, you drop in an SDK and like you're done, but that makes you like, have to give up a bunch of control some of your UI/UX. And so we think developers really resonate with that sort of like API first approach, where we do all the complicated, heavy lifting for authentication, but they still get to own that user experience and build their product around it.
CW Yeah, the black box is nice for prototypes. But then beyond that, you're just like, I have no control over this. I hope it works. And you just have a hope and a prayer.
BP To me, and I'm not here to be your marketing problem. It sounds sort of like you know, when I think of Stripe and how they succeeded in what it is plug and play for payments, yeah, it's like that. But for auth, right? Like, let's start by building a great API, great Docs, let's not force a one size fits all model. And like, you can just plug in and go, and they kind of solved that problem at scale.
JL Yeah, that's exactly right. We probably overuse the Stripe for authentication analogy. This sort of initial like, conversation that Reid and I had, this was back in like, December 2019. We were catching up over coffee. And we were complaining about how hard it was to build authentication. And the words that were uttered were 'why isn't there a Stripe for authentication?' And so that was sort of like the original idea here. And I think seeing Stripe, seeing like Plaid's experience as well with API versus SDK products. I think that gives us like a bit of a unique lens here about building that API first solution and what that looks like.
[music]
BP Alright. I am Ben Popper, Director of Content here at Stack Overflow. You can always find me at @BenPopper on Twitter, email us podcast@stackoverflow.com. And if you liked the show, do leave a rating and a review. It really helps. Cassidy, who are you?
CW I'm Cassidy! You can find me on the Internet @cassidoo on most things. And if you can't find me there, I don't know what you're searching for.
BP Julianna, who are you? Where can people find you? Where can they learn more about Stytch?
JL I'm Julianna, I'm the co-founder and CTO here at Stytch. You can find me online Twitter, etc @juliannaelamb. And if you want to learn more about Stytch, we're at stytch.com.
BP Alright, well, thanks so much for coming on. We appreciate it. And yes, I would test your password-less future. I hope we get there soon.
CW Yeah!
JL Awesome. Thanks so much for having me.
[outro music]