Reed McGinley-Stempel: Authentication Without the Friction

I love talking to folks that have really strong founder-product fit, where they've seen a problem's existence and then they really set out to solve it, and in the process have created a pretty valuable product for lots of people. You and Julianna, your co-founder, really fit that bill. What was the lived experience that revealed this particular problem to you guys? And how did you set about going to solve it?

Julianna and I met back in 2017 when we were both working together at Plaid, the fintech API. Around 2018, 2019, we were both working on the same product at Plaid, which was bank account authentication. Anyone that's listening to this podcast, if you've ever connected your bank account to Venmo, Coinbase, Robinhood, name any fintech, you've likely used Plaid and this bank account authentication flow.

As we were working on that, we were running into two major issues that ultimately led to our frustrations with the current auth landscape and for us to found Stytch. The two big problems we were dealing with at Plaid were that, one, the number one source of drop-off in our funnel was people forgetting their password when they wanted to connect their bank account. We were losing, at the time, over $100 million in ARR just in terms of people forgetting their password and not converting, because we only made money when you successfully connected that bank account to Venmo. So that was one big issue we had, conversion, the friction flow of actually someone connecting a bank account.

The second component is maybe something people will think about more when they think about authentication, which was security-related. The number one way we were seeing account takeovers of people's bank accounts, where money was being drained, was that users were reusing the same password at their bank that they used on other online services. One of those online services, say Target, Best Buy, whatever it is, would get hacked and breached. Then you'd have these millions of usernames and passwords available online and on the dark web. You'd start seeing these credential stuffing attacks against Plaid customers, against Plaid itself, where people were just trying to figure out what percentage of those users breached at Target reused the exact same credential pair to access Wells Fargo or Bank of America or Chase. You'd be surprised that it's a significant double-digit percentage that fall into that bucket.

So for us, there's two different angles we were trying to solve for our own purposes at Plaid. One was, how do we improve authentication from a security lens to prevent account takeover? And two, how do we also reduce friction to make sure we can get more users through the funnel, so our customers are happy, like a Coinbase or Robinhood, but also we make more money in that equation.

What I think was interesting, and what led to a couple of light bulb moments, is that usually when people think about security, you hear that you can't increase security unless you add more friction. But one of the areas where that's not true is typically authentication, where a lot of the friction comes from the fact that we rely on humans to do a lot of their own security settings. What I mean by that is you probably get advice, or you've given it to your parents, which is use different strong passwords across every different service you use online. In a lot of ways, we're just pushing the actual security obligation and requirements to the end user, and users will find shortcuts when they have a lot of friction to deal with. One of those shortcuts is reusing that same password for 100 different accounts.

One of the things we were exploring at Plaid was how could we actually flip this equation on its head, provide a lower-friction form of authenticating, whether it's sign in with Face ID, sign with Touch ID, email magic link, phone number verification, and by doing that, both increase conversion, but also minimize the surface area for attack for a typical user.

We tried to build this in-house at Plaid. We presumed there had to be some Stripe for authentication service out there that was going to make this dead simple and one sprint for us to incorporate. Instead, what we found was, continuing with that analogy, there are a lot of PayPals for authentication, where you could buy a widget to do authentication, but you could not get the fine-grained, API-first flexibility and design control you might want if you're a company like Plaid or if you're just design-centric culture.

That plus the fact that we found a lot of these companies have been architected in the 2010s around the password as the primary building block. The password is still not dead, so obviously we still need to support that at Stytch, but there are many different ways you architect a solution when you're thinking about what comes next in the 2020s, as we started a little bit after COVID. So that's a little bit of the background on starting Stytch.

In simplest terms, what does Stytch do today?

If somebody is trying to build a sign-up or login form, we try to make that as simple and powerful for developers as possible. When I say Stripe for authentication, what we mean is the same way people want to make it really easy to build payment forms online, we try to make it really easy to build authentication forms. So login, sign-up, keep a user logged in with session management, things like that.

You make it sound super simple. But the average internet user has something like 240 different online accounts, some for work, some personal. Identity can feel as simple as typing in my password, and it either lets me in or it doesn't. But there's actually this complex web of different pieces of identity: enterprise identity and access management, customer identity and access management, privileged access management. So what do you focus on at Stytch? Are you totally focused on helping developers build identity and access management for end customers? Or does it go more broad than that?

We're very focused on the customer identity market. So to your point, the end customer that is accessing an application or website via that sign-up or login form. For us, that's both consumer applications, where consumers are customers, and B2B SaaS applications, where another business is your customer.

The one section we do not compete in is workforce identity management. So you at Contrary are logging into an internal application and you need to log in with single sign-on, which you might be using Okta or Google or something like that for. The one thing where sometimes it gets a little confusing as you look at the competitive landscape is our biggest competitor is a company called Auth0, who's the big incumbent that is owned by Okta, and they were acquired about a year and a half after we were founded. We compete directly with them, but we don't compete with the portion of Okta that just does workforce identity. That's sometimes an area where we find we have to explain the subtle differences.

When you go back to the problem statement, passwords impact both the workforce and customer side of things. Everyone's familiar with the pain. I think I reset my Apple ID password every time I have to use it. It can feel super straightforward to say, let's get rid of passwords, but it starts to get really complex. So walk me through how your product has evolved. You set out to make a dent in this password pain, but what does that mean from a product perspective? What do you build first and what comes after that?

When we started out, we knew we'd have to support many different options or modalities of authentication. We were very bullish in particular on passwordless. So we knew we'd have to support things like Face ID, Touch ID, sign with magic link, sign with phone, sign with Google, Microsoft, all of those options. We actually had a debate early on where we didn't know if we were going to have to support passwords or not. I think we were arguing both ways. One, we want to do a lot of brand marketing around the future. But two, there is the pragmatic approach that a lot of companies might not be ready for the change management involved in getting to that future.

The initial product-market fit was actually just with our passwordless products. That was where we signed our first six-figure deal, probably a year into the company formation or something like that. That's great. But then you started to realize, as you tried to sell the exact same portfolio to a more risk-averse enterprise, that we started getting a lot of CIOs or CTOs or CISOs that would say things like, "I don't want to do the change management of making people completely drop their password." So what we learned was, even if we're very bullish on that future, we had to be a bridge for this. We could be architected in a way that meets both the past and the future better, but we had to at least meet people where they were when it came to offering passwordless and passwords.

So what does that look like from a product? We have to support all these different options to log in and sign up. We have to make it extremely configurable, but also easy for developers to set up. If you wanted to offer sign with Google and sign with passkey, which is the Face ID, Touch ID, we need to make that an SDK configuration, so you can just have a couple lines of code with Stytch. We also have to build a robust backend API in case you want to own all of the UX and UI yourself. Overall, you can think of the business as there's core products that an end user sees, and that's the authentication piece, and there's all of the developer experience products we build, such as APIs, SDKs, developer dashboard, things like that.

Can you paint an example of that? Maybe there's a well-known service or a specific customer of yours where they built an interface to enable passwordless logins, and they're managing maybe millions or tens of millions of users. What's the scale of something like that?

I was just coming from an AI event last night, so a couple of our AI customers are top of mind, and I think it's good to call out a couple because you'll see how different this could be. A couple of large AI companies that have migrated from Auth0 to Stytch are Tome, which is a presentation tool for building really seamless slides, and then You.com, which is like a Perplexity competitor, focused on marrying the browser with chat when it comes to GPT-type experiences. Both of those power millions of users accessing the different products.

But if you went to their websites and you click to log in, and it's been a couple of weeks since I've been on their websites, but my recollection is you actually get two very different experiences. One of them is fully passwordless, Tome. I believe they're using sign with Google and email magic link. The other one, You.com, uses, I believe, sign with Google, sign with Apple, email magic link, and give passwords as an option so that users can choose.

They even implemented it in different ways. I believe if you go to You.com and click login, it does the interface when you're still in the browser chat, because it doesn't want to redirect you to another page where they're trying to keep you invested. Tome actually puts you onto another page, because they're trying to put you into a formal onboarding. You haven't tried the product yet.

The auth products are being powered by Stytch, but also even just that embedded experience is being powered, versus if you are using something like an Auth0. The reason I call it PayPal for authentication is, once you've seen it, you recognize it. It's the same undifferentiated box. You wouldn't be able to embed it the same way that someone like a You.com does, where it's actually overlaid on a page.

You mentioned some of these modalities you have to support, and that brings with it this interconnected stack of tools and integrations you have to build. Walk me through the tech stack of where Stytch exists, starting from the landing page to what the customers might have to build themselves or build with Stytch's help. And what are maybe some other backend systems a customer might need to use as well?

Let's take an example, like a Tome, where if you go to their website and you hit sign up or login, they're using our headless SDK to incorporate the sign with Google, which is effectively an integration of OAuth as a protocol, so there's a lot of different handshakes happening there. They're also using the Stytch SDK to embed the magic link sign-in, where we're also handling not just the auth logic, but also the deliverability of that email. For example, one of the things we build into our product is failover amongst different programmatic email providers, so that if SendGrid goes down or Postmark goes down, you don't have any downtime when it comes to a key service like sign-up or login.

They have the option of whether they want to own the UI components or whether they want Stytch to own that. I would say a lot of earlier-stage companies give us the UI components entirely and use our UI in our SDK. Tome is someone that has actually a really great design team, and they know exactly, pixel perfect, what they want their UI to look like. So they are using our headless SDK so they can get full control over the actual components, and then we just handle all of the OAuth protocols, the magic link protocols, et cetera.

After you authenticate, we handle what is called session management. This is when you're on a website and you go from one tab to another, or you go to your account settings page, you obviously don't have to log in every single time. The reason that's made possible is that you're having a cookie set on your browser or in your application that allows them to recognize this is Kyle, who just logged in six minutes ago. The session is still valid because it's maybe an hour-long session or 24-hour-long session, so we're not going to make him sign in again. We manage all of those requests as you continue to navigate the application.

The other thing we manage for them is that we have a developer dashboard where, say they have a support case or they want to modify data about an end user, they can effectively use it as a UI for interacting with their user database.

What we don't do, or where we'd say you maybe bring in other tools depending on what you're looking to do, is usually I would say most people are mirroring our user data table in whatever database they're choosing. You could use us as the source of truth, but a lot of times you're still going to stick that in PlanetScale or MongoDB, whatever core database technology you're using.

The other area where it depends on what they decide to do is that we come with a lot of fraud tooling out of the box, like device fingerprinting, invisible CAPTCHA. I think someone like a Tome and a You.com and other customers like Replit use that. But otherwise, you might use us in our fraud products next to Cloudflare or some other DDoS protection service. Usually, we handle everything related to sign in, sign up, keeping a user logged in, and how you manage that user data. The core source of truth would probably live in your actual database layer, and then you might add on additional tooling, such as product onboarding tours, additional fraud features beyond Stytch, things like that.

You're at a pretty interesting point, it feels like, where you control this entry point for these end users. So where do you go from there? I know you guys have launched some fraud products. Do you go deeper into fraud? Are there other aspects of the product you might expand to take over more of the customer's experience?

We've been going very deep into fraud, and I think you'll see a lot more in 2024 and 2025 there. The reason is that one of the other issues we had with the incumbents is that we feel like an Auth0 does a good job of selling you a front door to your application. Obviously, it's a widget and we have some issues with that, but it is a front door. Where I'd say you start to see it as you scale break down is that they are not responsible for the security system of determining whether it's a forged key, somebody's stolen credentials or phished credentials trying to access that door. They're also not great at if somebody's taking a sledgehammer to that door. This is where you get mass credential stuffing. They have a feature called anomaly detection you can turn on, which will give you some insight into things going wrong in your application. But for the most part, what we found, both in our past experience at Plaid, but also virtually every company, once they hit scale, has to choose another fraud vendor beyond Auth0 if they want to get the level of granularity of bot detection, malicious detection, things like that.

So we've tried to go really deep into how you actually give someone the front door and the security system, and be able to alert them, but also take action on preventing the sledgehammer, preventing the forged key. The most popular product in our fraud portfolio there is device fingerprinting, which is effectively an invisible piece of JavaScript that gets run on the page that allows us to give a reading back to the customer that says, this is Kyle, who you've seen before a week ago, or this is an anonymous user you've never seen but is a real human, or this is a bot emanating from XYZ region. They're running curl, or they're using a headless browser, because they're probably going to try to abuse your AI compute, Tome, or your AI compute, Replit or Hex or whoever the Stytch customer is in this case.

We're going very deep in that, both because we think there's a big gap, but also working at Plaid, one of the things we saw a lot of was the way auth and fraud gets tied together, where the problems are not just auth problems, it's also how somebody's trying to steal somebody's identity. So we cared a lot about that, but also felt that we were pretty well positioned to build solutions there, because not many people know this, but the way Plaid originally started was by reverse engineering mobile banking APIs. That was how you actually created a connection with Bank of America from Venmo. Plaid was effectively a proxy that was showing itself to be an end user on behalf of the end user. That was legal based on things like Dodd-Frank and other acts like that, where users have a right to their data. But there's a lot of bad actors that are trying to reverse engineer sign-up or login endpoints, so they can either steal a user's existing account or create a free account and abuse free credits or AI compute or any other generic type of compute. We knew a lot of the ways you would stop that, because we had been on the other side of how you actually reverse engineer something. So we continue, in addition to device fingerprinting and our invisible CAPTCHA product, to embed a lot of additional features there that marry the auth and fraud problems we saw.

There is this build-or-partner dynamic as you go deeper into a wide variety of use cases. There's a massive number of modalities for sign-on, and there's also a ton of different types of fraud and layers of complexity: considering the device, understanding whether this user's location makes sense geographically, getting into behavioral fraud. So do you dive deeper and deeper into fraud, or do you stay anchored to the sign-in process, maybe touch on fraud, and then point the customer to other folks with more in-depth fraud experience?

So far, and I think we can go pretty far with this approach, but we might use partners to augment it or extend it in the future, the way we've thought about fraud detection is there's deterministic and there's probabilistic fraud detection. We are much deeper in the deterministic state, which is when we tell you something's a bot or not a bot, we have 100% certainty that that's the case. Zero false positives is something we live by, because that hurts your user onboarding. We also want to be able, when we tell you something is fraud, to tell you the exact signatures of what led us to understand that was a bot or whatever it was.

The reason I think that makes a lot of sense for the auth vendor to focus on deterministic rather than probabilistic is for auth, you would always expect that to be deterministic: did Kyle actually verify this email or this password? We're trying to bring that same approach to the fraud detection side. There is merit to having probabilistic things and putting that into your engine as well, such as behavioral. For that, we've been more keen to partner with other folks that go really deep on typing inference, how you hold the phone, telemetry, things like that. But for the most part, we're really happy to continue digging into the deterministic approach, where we can tell you absolutely what is at risk or not at risk and why.

Additionally, what we found is typically when people get to the probabilistic basis, they want to build their own model anyways. Someone like Replit is a really sophisticated anti-fraud team. They are using our device fingerprints to both inform how they treat traffic, but also so that they can build their customized model for detecting fraud. We like to be the deterministic input there, which then they can build the probabilistic model based on all of their inputs and usage data, where it's always going to be harder, if we try to build a probabilistic model that works for everyone, for it to be tailored enough that it is as effective as you could build in-house.

I want to switch gears and talk about the competitive landscape. We're going to talk about Auth0 and their acquisition by Okta, but before we do that, let's lay the groundwork for the status quo. My sense is that while there are players trying to tackle different user experiences, the vast majority of folks are pretty much still building this stuff in-house. Even something like Auth0 is probably super common with tech startups, but in the grand scheme of everyone logging into something, my guess would be that the majority is still pretty manual in-house tools.

The last estimate I saw, I think it was from Morgan Stanley, and this would have been a year ago or so, but I think the estimate was still that 80% to 85% of the market was white space, meaning in-house builds. One of the reasons we really like the API-first approach is it helps us sell to people that have historically been in-house. Some examples of that are companies like Clearbit that migrated to Stytch after being in-house for a decade or Homebase, which is a payroll company that was in-house for a decade that migrated to Stytch. The API-first model matters a lot to try to take that white space, because otherwise there's probably going to be a lot of things you don't want to unwind about your decision-making over the last decade you've been in-house when you look to migrate. If you have to go to a widget-based model, or that PayPal prefix menu, you end up having to rewrite a lot more logic than if you have a more flexible option.

So to your initial question, yes, a lot of it still is in-house builds. Then of the non-in-house builds, where people are using a vendor, Auth0 by Okta is by far the biggest player. Though it's always funny, it's similar to Microsoft Teams taking off. Microsoft is just a massive competitor of its own, but it's such an insular ecosystem that we don't even see Microsoft in that many deals, because I think if you're on Microsoft, you're all in on Microsoft. So instead, we're, in a way, more the Slack in this market, where you're trying to compete for the non-Microsoft businesses.

Let's talk about Auth0. First, some context for our listeners. In February 2021, Okta acquired Auth0 for $6.5 billion. There are two important data points to pay attention to here. The first is that when Okta bought Auth0, I think their market cap was $35 or $40 billion. Today, their market cap is $13 or $14 billion. So Okta certainly saw a pull-forward during COVID around digital adoption. The second is this report I saw that said by 2026, the customer identity and access management component of Okta's business, which is essentially Auth0's product, represents something like 50% of Okta's revenue. So that's $1.5 billion of revenue to go get. Auth0 got built up as the first attempt for people to not build this in-house, but the opportunity still feels like it's in its infancy. So let's walk through the difference between you and Auth0. If I'm somebody who's been using Auth0 for a long time and I want to switch to Stytch, what is the experience going to be like managing that change?

Maybe one thing I'll add to that flipping you're seeing of customer identity versus workforce identity. I haven't seen an analyst comment on this, but my guess is the problem Okta was running into with core workforce is that you are capped by the number of total employees in your markets, because you're a per-seat license. Versus if digital apps and websites are going crazy, you're only capped on the customer identity side by how fast the number of new apps users use is growing, which that's been growing much faster than the number of employees in the U.S., just take North America as an example, over the last five to 10 years. So that's my guess for why that flipping, and to use the crypto term, flippening or whatever, might be happening in the customer versus workforce identity TAM.

But in terms of somebody moving, what we've seen is the Okta acquisition of Auth0 has led a lot of folks to pick up their heads and say, do I want to continue investing in this vendor, who seems to be putting a lot of their effort into now price control? I've seen over the last few years since the acquisition, prices have been going up usually 30% to 50% year over year for Auth0 customers, because Okta is realizing they're trying to consolidate the market. They're trying to see the value of the acquisition.

As people have picked up their heads, the big differences you'll find if you migrate or consider migrating to Stytch is, one, you will be able to access an API-first model. So you can own way more of the UX and UI when it comes to how customers interface with your product, which obviously matters to the degree that that is a differentiator. Do you feel like a native Robinhood experience, or do you feel like this company that is outsourcing a key part of the first user experience to PayPal or Auth0 in this example?

The second piece is the auth and fraud component. Even before AI, phishing attacks, bot attacks, all that was rising really precipitously. A lot of people were ballooning their vendor spend if they were using Auth0, because they were also adding another fraud vendor. I think that's just become more pronounced as the new AI risks of clone voices, et cetera, come in terms of account takeover. So what you get with Stytch is you just get to consolidate that to one vendor, so you don't have to worry about who do I pick for auth, who do I pick for fraud. You don't have to use us for fraud, but probably about 50% of customers bundle them, because they see really nice unit economics from that. The tight coupling actually helps eng teams move faster on making some of those decisions for what to block, what to challenge, et cetera.

The last piece I'll mention is for B2B companies like, say, a Tome that migrate from an Auth0 to Stytch. The biggest thing they see is that we have a very different data model architecture for how we do B2B authentication versus Auth0. Ours is built on what we call an organization-first data model versus user-first. The reason that's powerful is typically in B2B, where you spend all of your time as you scale as a B2B auth team or identity team is that you get all of these permutation requests from new enterprises. You sign Nike, you sign Cisco, you sign IBM, guess what? They all have typically slightly different requirements in terms of how they want to auth into your dashboard or into your product. One of them will say, "Our IT team requires all sessions be less than an hour." One of them will say, "You need to single sign-on with our homegrown IdP. We don't even use Okta or anything like that." Another one will say, "I need directory sync," or SCIM is the protocol, so that when a user leaves our company, you deactivate them immediately so that I don't have any in-the-air memberships floating around where people might have access to things they shouldn't have. One of the things we've done on the B2B product is just made it so all of those are simple API requests to comply with any enterprise auth need that comes up.

So that's typically the biggest changes you'll see: the API-first approach, the auth and fraud combination, and if you're B2B, a much more natural data model to scale with, so you can support many of those enterprise requests over time.

The migration itself, usually for a small migration, less than a week. For a large migration, say a Tome, they were a few weeks, but they were literally migrating tens of millions of users. We have specific endpoints that allow you to exchange your Auth0 sessions for Stytch sessions, so you don't even have to log out users. You upload all of the users and migrate them, maybe migrating hashed passwords if you still have those, and then you're doing the session cutover with Stytch, which allows you to fully onboard everyone to Stytch.

When you go back to this flippening of people recognizing the opportunity that exists in customer IAM, it feels like what is really going to change is not just the number of applications people are using, but this realization of the benefits of leveraging a tool versus building in-house. But that could be an oversimplification. So as you look at all the things people hate about Auth0 or love about Stytch, what are the other things really driving that flip or that decision?

I think you're right that just generally every survey you see across CTOs and leaders is the buy versus build. The buy decision gets much easier just generally across the software stack each year. It's not a massive change each year, but it's been building up over the last five to 10 years. That component matters a lot.

I do think the other component has to do with the fact that the threat space has changed a lot when it comes to identity. Things like AI security have come up in maybe 50% of conversations I've had with CTOs or CISOs over the last year. Passwordless was an inflection like this. I think AI is another inflection, where these things that become big worries at the exec level do push a lot of the thinking of, is this something we're going to have a good enough pulse on that we should try to own internally? Or if it's a threat space that's changing often enough, should we just outsource this?

For a lot of cybersecurity, they've already made a decision, going a decade past, that that's not something you should try to build in-house. I think auth was something that a lot of folks still building in-house had disconnected from the cybersecurity side and said, well, yes, we're still going to buy these fraud tools, but maybe auth we build in-house, because it's an OAuth handshake or it's a password database or it's an MFA we're adding with Twilio or something like that. As you start to see identity become the last frontier of where a lot of the attack surface is growing, because of improvements in phishing, in AI believability and cloning voices or mimicking writing style, I think you're starting to see a lot of people realize the threat space grows so fast there that it makes sense to just buy rather than build.

That's a good segue into the last two questions I want to dig into with you. Let's talk about some of the risks and obstacles you're going to face over the next few years. Being that first line of defense with things like identity as a threat vector certainly puts you guys at the center of the conversation. If there are issues with your ability to securely manage authentication, that's obviously a huge problem for your end users. So that might be one, as you start dealing with the implications of things like AI security, but what are the others you're keeping a close eye on?

I think you hit the nail on the head on the one I think about is most existential to Stytch, which is making sure, since we are trusted as the secure front door and security system for our customers, that our security of our infrastructure, our product, et cetera, is above reproach. That was something we thought about when we started the company: how do you build this into the development of the product and the monitoring of the product from the beginning?

One of the early decisions we made was we looked around and we looked at the security engineering firm that Plaid used, which is a firm called Latacora. We had always, in our direct experience with them, been really impressed, because if you think about it, Plaid is one of the most valuable honeypots of data that any attacker or even nation-state could try to breach, because there are hundreds of millions of raw usernames and passwords stored by them. Obviously, that started to change a little bit as official bank OAuth came around, and now they're storing tokens rather than something like username and password. But while we were there, that was definitely the thing we thought a lot about at Plaid.

So we'd worked with this really amazing security engineering firm that's 25-plus security engineers called Latacora. They have application security engineers, cloud infrastructure security engineers, pretty much every flavor, mobile app security engineers. We realized as a six-person seed company, we are never going to be able to hire that level of expertise in-house to start. Obviously, we're going to grow our security engineering team over time. So we started working with them right at the seed stage. We were paying them much more than even AWS at the time, because we were so small from a usage standpoint. But for us, it was a very good calculation, because we knew that was the one existential risk to the company.

The other thing that deepened the relationship was that our Series A, they had started a fund to invest in companies they're excited about, and they put about 10% of their fund into Stytch. That was a great vote of confidence, where they had had a lot of issues with Auth0's approach to security in the past. They've given a number of YouTube talks and speeches where there's been a lot of issues. Not everyone's aware of this. Auth0 had a very bad security issue five or six years ago, where if you passed in "none" as the JWT algorithm field, which JWT is how you manage sessions, you could impersonate any user on any Auth0 customer. They obviously ended up patching this. But it was good to get this vote of confidence and get this security engineering firm with skin in the game early at Stytch, who has continued to scale with us. Now we've, of course, added an in-house security engineering team as we raised the Series A and the Series B.

That's always going to be your biggest risk, your security infrastructure, because other people are outsourcing their security to you. I'd imagine Cloudflare and others and Okta, et cetera, have the same answer. Even Okta's had a couple breaches in the last year, and obviously, they're big enough where they can survive that. We're not big enough where we can survive that from a brand reputation standpoint, so we need to hold ourselves to a different standard and bar there.

The second big thing we talk a lot about is no U-turns when we're building products. This is where architecture matters so much. I think it's the famous Frank Slootman quote about past companies he's worked at, why they've worked well when he's been a CEO, and he's always given credit to the architecture. If the underlying architecture is not right behind the product, you will always hit some TAM cap, because it will be way harder to do the U-turn to improve the architecture than it will be to just solve it from the beginning. As a 65-person team, we just can't afford U-turns when it comes to product velocity, time, resources. So I'd say the existential risk of security, the more executional risk for us is just making sure we architect things so we don't have to perform U-turns.

On the other side of the coin, other people's risks are sort of your opportunity. As AI attacks become more prevalent, people worry about the stuff they're building in-house and want a dedicated service around specific forms of protection. We've also talked about the extensibility of the platform and how you're broadening into things like fraud. What are the things most top of mind, whether it's continuing to broaden the product surface area or other use cases or end markets? What are the key milestones you're going to be tackling over the next few years?

On the customer identity side, we've talked about some of the three probably biggest bets we're making, which is that the architecture was wrong in the previous incumbent space; it wasn't API-first. That's one bet. The second was that there could be a far better architecture when it comes to B2B organization data models. And the third is this combination of auth and fraud, going very deep on the security settings and offerings in customer identity. Those will probably continue to be our big bets in customer identity.

The other bet we haven't talked about is at some point, I don't think this is near term, but I think it will make sense at some point for us to at least consider the workforce identity market and see what makes sense, what doesn't make sense. We have to be very careful and cautious about that, because I think one of the reasons the Okta acquisition of Auth0 has opened up the floodgates of opportunity for others like ourselves is actually Okta, I think, underappreciated how difficult it was to sell to those two different personas, where Auth0 and customer identity sells to developers. Okta and workforce identity sells to IT admins.

So we are very interested in workforce identity, and we do think there's going to be a lot of innovation there throughout the 2020s. We still have to figure out what Stytch's ultimate role is going to be, or absence of a role, in that. Maybe it's partnerships, maybe it's something else, but I do think you see a lot of these large CIAMs like Ping Identity, ForgeRock, Okta now, where at some point you bridge customer and workforce identity. I think workforce identity will continue to be really critical, so we'll at least need to keep an eye on what we want to do there.

It feels like there's an interesting shift happening with enterprise applications. People have been talking for years about the consumerization of enterprise software, but that was usually more around things like design and usability. There's also this consumerization of infrastructure. When you look at applications like Rippling, they're trying to make a very arduous workforce experience much more seamless with widgets, building everything into one place across things like HR and IT. It feels like there is an opportunity to look at workforce identity and access management as a thing that could be consumerized, which could potentially be a big opportunity for you guys, because you have such a flexible API.

Totally agree with that. The one other thing I'll mention, that could be workforce, could be customer, that we're keeping an eye on is AI obviously brings a lot of interesting security opportunities for us. The other thing I'm curious about from a UX and UI perspective is when AI agents actually get to the point where we're delegating tasks for them that otherwise we would have logged into a service to perform. That to us is going to be really fascinating, because AI agent auth then is going to be a combination of machine identities being mixed with customer identities, and you're going to need human-in-the-loop MFA maybe occasionally for certain things. It used to be total sci-fi. Now it's still somewhat sci-fi about when we'll get there, but it does seem inevitable that we'll be at a future at some point in the 2020s where AI agents are a large source of the traffic that Stytch is dealing with coming into an application, and figuring out the right way to determine which is valid, which is invalid, which is valid but requires step-up for additional approval, things like that.