Stytch: Kill the Password

Created

Jan 19, 2023 8:01 PM

Why Passwords Suck

When I spoke to Gaurav Ahuja, the Thrive partner who led Stytch’s Series A and introduced me to the company, I asked him to lay out his investment thesis. He told me there were five points to his thesis, starting with the enemy:

First, the future should be passwordless. Actually, back up, first: passwords suck. And they suck in three ways:

They’re a terrible user experience.
They hurt user engagement, conversion, and revenue.
They’re a burden on IT support.

Gaurav’s a really nice guy. That’s the meanest thing I’ve ever heard him say. But passwords deserve it.

If humanity were designing authentication from scratch today with no preconceived notions, we would never come up with a system in which everyone has to memorize dozens of word/number/character combos and type them in to do anything online. We use passwords today because we’ve always used passwords. They’ve been around for millennia. Chances are, when you were a kid, and you wanted to get into your friend’s pillow fort, they asked you for the secret password.

But passwords are a relic. In a July blog post, Stytch walked through the history of the online password to explain why they no longer make sense. Each decade introduced its own authentication paradigm:

In the 1990s, as the internet went mainstream, passwords were the dominant form of authentication.
In the 2000s, as users opened more and more accounts, password managers—which encrypt and store online login information—were introduced to help them handle this increasingly complex landscape.
In the 2010s, as online technologies advanced, alternative auth methods—often referred to as “two-factor authentication”—embedded low-friction, secure hardware (like biometrics and YubiKey) and software (like APIs for programmatic text and email) into the user experience.

Today, we’re stuck with a weird compromise: enter a password and then do the thing that’s actually secure, like scanning a face, entering a texted passcode, or clicking a magic link in an email or text. The second factor hasn’t eliminated the first. In fact, thanks to the COVID-induced mass online migration, all of us are juggling 25% more passwords now than we were in 2019…

… and we forget them, a lot. In 2016, Intel Security found that 37% of people forgot at least one password every week. That’s undoubtedly gone up as the number of passwords we need to remember has more than doubled. A more recent 2019 study by HYPR found all sorts of damning things about passwords, including:

78% of respondents required a password reset in their personal life within the last 90 days
57% of respondents required a password reset in their work life within the last 90 days
35% Of people keep all their passwords in notebooks, Excel files, sticky notes, etc... (Password managers like 1Password are great, but they’ve struggled to gain mass adoption and usage)
72% of individuals reuse passwords in their personal life while nearly half (49%) of employees simply change or add a digit or character to their password when updating their company password every 90 days.

The result is a situation that’s incredibly annoying for users…

...and terrible for security. Many of the major headline-grabbing hacks of the past year have been due to the vulnerabilities that passwords create. The Solar Winds and Colonial Pipeline hacks earlier this year both involved password weaknesses, and 81% of all internet breaches can be traced back to weak or stolen passwords.

Beyond hacks, though, passwords are bad for business. According to Stytch, 75% of people who click “forgot password” abandon whatever they were trying to do. Reed told me:

Passwords are an extremely high-friction hoop that we make users jump through, and this friction creates drop-off in both user sign-up and login flows, directly hitting companies key metrics like customer acquisition cost (CAC) and user life-time value (LTV).

It’s no wonder. This diagram that Reed and Julianna shared with me shows the process that people typically need to go through to reset their password:

To be fair, that’s exactly what someone trying to kill the password would say and exactly the diagram they would share. To which I’d respond: I bet you a dollar that you’ve gone through that exact flow at least once in the past month. I have a terrible memory and am very disorganized. I go through it once a day.

Plus, Reed and Julianna had great jobs. They didn’t have to do this. They’re not filling in anti-password facts post hoc; they started Stytch because they lived password pains every day.

The Founders’ Journey to Stytch

Julianna and Reed seem almost lab-designed to be the perfect Stytch founders.

Julianna grew up in Sun Valley, Idaho, home to, among other things, Allen & Co’s annual tech conference, dubbed “Billionaire Summer Camp.” After a year of high school in Paris and freshman year at Georgetown, she transferred to Stanford, a small engineering school in Palo Alto, California.

Reed was raised in Las Vegas, and there, he must have studied just a little bit harder than Julianna, because he ended up attending the nation’s greatest institution of higher education: Duke University.

(Story pause: after I wrote that last sentence, I went to pick up tickets for a Nets game on SeatGeek, and wouldn’t you know it… I forgot my password.)

Anyway, where was I? Sorry, that was distracting, lost my train of thought.

Oh yeah. So Julianna was at Stanford and Reed was at Duke. After school, Reed did a Fulbright in Germany and a stint at Bain & Company while Julianna got a job as a software engineer at Strava.

(Fun coincidence: on Tuesday, Max, an engineer at Stytch, made Strava art with the Stytch logo by running a path that spelled out the company’s name.)

Stytch’s Twitter

In May 2017, Julianna made the move over to Plaid as a software engineer and three months later, Reed joined Plaid on the growth team. While at Plaid, both Reed and Julianna ended up working on a low-key critically important piece of Plaid’s product: bank account authentication, Julianna as an engineer and Reed as a product manager.

For those who haven’t been reading Not Boring closely when we’ve discussed Plaid in the past, it lets developers connect their apps to users’ bank accounts. If you’ve used Venmo or Robinhood or Coinbase, you’ve used Plaid. You click a button to connect your bank account, choose your bank, and fill in your credentials, and Plaid connects the accounts.

Justin Gage, Technically

The problem is, if you’re like me, you’ve also failed at using Plaid because you forgot your bank account password because you just have it auto-fill in your browser or turned on FaceID in the app. So you enter your best guess, watch as the screen loads, and then moan as it tells you you got it wrong and asks you to do it again.

Plaid

Sometimes you do it again. Sometimes you reset your password. Sometimes you say nevermind.

Authentication is such a crucial challenge for Plaid because its customers rely on Plaid’s APIs to connect with their user’s most sensitive information, their bank account details, which also happens to be mission critical to how Plaid’s customers make money. No bank account connection, no funded accounts, no transactions, no revenue. That means that Reed, Julianna, and their teams had to optimize both for security and for user experience. They couldn’t let hackers in, but they also couldn’t keep people from connecting their bank accounts. As Reed explained it:

As Julianna and I worked on an array of projects focused on improving both the security and conversion in bank account authentication, we realized that our biggest security and user experience headaches all stemmed from the same technological relic: the password.
And anytime we had to build anything related to authentication, we found ourselves building the authentication features out internally because none of the incumbent solutions had a flexible enough product to enable what we wanted to do.

When Julianna left to go to Very Good Security as a Product Manager in 2019, she found the same challenges awaiting her. “I ran into many of the exact same authentication headaches,” she said, “as we migrated away from a large incumbent vendor (Auth0) to an in-house authentication solution due to the inflexibility of Auth0’s product.”

That’s not necessarily a criticism of Auth0. The product does what it was designed to do. It’s a widget that’s really easy to plug in. It is, however, a criticism of our nemesis: the password. Because Auth0 is built for a world of password-based authentication, it’s actually wise to push customers to use widgets hosted by Auth0 so that the customer never has to tough or store sensitive credentials. The challenge for Auth0 is that we’re moving to a passwordless world.

Get rid of the password, and you get rid of the concern around storing sensitive user data. In the passwordless world, you can design flexible, developer-friendly products and let developers figure out where and how they want to authenticate users in a way that fits their specific product.

That’s the world that Julianna and Reed decided to explore. After Julianna left Plaid, the two kept in touch and met up for coffee every month or so. In December 2019, over one such coffee, they shared their ongoing frustration with passwords and the lack of a “Stripe for Authentication,” a simple, flexible product that developers love and that improves the end user’s experiences on the internet.

They spent the next six months researching. They talked to dozens of their friends at other tech companies in the Bay Area, and none of them knew of any good solutions, but many of them had the same frustrations. They were wasting sprint cycles and valuable engineering resources building their own authentication flows in-house.

So in June 2020, they quit their great jobs and founded Stytch. I’d encourage you to listen to the fireside chat that Gaurav and I had with Reed and Julianna to hear the story of the 0 to 1 founders’ journey in their own words:

So what are they building?

Meet Stytch: A Friction Reduction Company

Remember earlier when we talked about 2010 as the decade of two-factor authentication? And pointed out that the first factor (passwords) is bad and the real magic happens with the second factor? What if we got rid of passwords and started with those second factors?

Companies like Slack, Square Cash, Medium, Monzo, and Revolut have already embraced the opportunity to go passwordless. I still remember signing up for Slack for the first time and getting my magic link to log in without a password. It was… magical. Those companies had to build those experiences in-house. They can afford it, and they have some of the world’s best engineers.

Stytch builds really easy ways for any developer to create authentication experiences that improve security and reduce friction. In fact, in our fireside chat, Reed mentioned that internally, Stytch refers to itself as a friction reduction company.

To accelerate this passwordless future, they’ve built an extensive platform for user management and passwordless authentication so that companies can stitch together (get it?) the authentication methods and user experiences that make sense for their user base and product.

Developers can integrate with Stytch through its direct API if they want to fully own the design and user experience.

Or they can use its customizable, front-end SDK (which wraps Stytch’s APIs) to get the user interface out-of-the-box.

Through these integration options, Stytch offers a number of different authentication products to developers:

Email magic links
SMS/WhatsApp/email passcodes
OAuth logins (e.g. log in with your Google, Apple, Microsoft, etc. credentials)

More Web3 options like Metamask are coming soon 👀

Session management

These are the table stakes. Stytch spent the first year or so getting to parity on authentication types while offering them to developers in a cleaner, more flexible way. Now, it’s innovating.

In September, Stytch launched Embeddable Magic Links. While all of Stytch’s first products dealt with how to authenticate and manage users once they hit the product, embeddable magic links meet the users where they are in order to reduce friction.

Let’s say a brand with which you have an account emails you about a promotion they’re running, with a big ol’ SHOP NOW button. Normally, responding to that call-to-action (CTA) would take you to their site, where you’d get hit with a login flow to be able to actually buy anything. But they sent you the email to your email address, just like they’d send a magic link to you to log in.

Stytch Embeddable Magic Links

Wouldn’t it make a whole lot more sense to combine the CTA and the magic link, so that by clicking, you arrive to the site already logged in? That’s what Embeddable Magic Links do.

And they’re not slowing down at Embeddable Magic Links.

Today, Stytch is announcing support for WebAuthn, its first biometrics product. WebAuthn allows companies to leverage built-in biometrics like TouchID and FaceID and external hardware keys like Yubikeys.

Later this quarter and next quarter, they’ll be introducing a number of new products that will further expand the platform’s capabilities, including:

Time-based one-time passcode support (e.g. Google Authenticator, Authy, etc.)
QR code authentication
Push notification login
Native mobile biometric support
More OAuth login support (e.g. Discord, Slack, Github, Facebook, Metamask, Phantom, etc.)

Each individual product that Stytch adds is another weapon its customers can use in the war on passwords, and another building block with which they can build more delightful and frictionless experiences that meet users where they are. Stytch is adding new products at an alarmingly fast velocity, filling the toy chest with more and more blocks.

That speed and breadth, combined with the API-First approach, is Stytch’s strategic angle of attack.

API-First as a Competitive Advantage in the Race to Replace the Password

Sometimes, for the companies that I write about, the main competition is the build vs. buy decision. That’s the case for Modern Treasury, for example. Customers decide whether they want to build something in-house or use a focused company’s software or APIs.

Other times, there’s intense direct competition. The opportunity has become obvious enough that both incumbents and well-funded startups compete to win. Passwordless is such an opportunity.

Stytch believes that a developer-friendly API-first offering with a robust offering of passwordless products is the best way to win. The logic to both is that customers will want to build authentication experiences and user infrastructure that makes sense for their own end-user customers, and that the dominant approach is to arm those companies with everything they need.

To win the market, they’ll need to overcome a series of foes.

The 800 pound gorilla in the space is Auth0, which we discussed earlier. Auth0 is a much, much larger company than Stytch, with a reported $200 million in revenue at the time of the Okta acquisition. It’s impossible to dismiss Auth0, particularly with the customers they already have and the financial and distribution support Okta provides, but Auth0 has made trade-offs that do not seem best suited for the current landscape, stemming from their belief in passwords. The first image they have on their website is of an Auth0 widget with email and password fields.

Auth0

As developers have become accustomed to API-first companies like Stripe and Twilio, it’s hard to imagine that all but the most basic will choose a widget-based solution head-to-head. You know that I’m a believer in API-first companies. I think that approach will win here.

Why? Authentication is right in the API-first sweet spot.

It’s mission critical -- every company needs to authenticate its users -- but non-core -- name a product that you use because of its authentication.

It’s more than that, though. Stytch believes that by building API-first, Julianna told me, “We can enable so many rich, flexible user experiences that wouldn’t be possible if we only built and sold front-end widgets for authentication.”

As an example, she told me about Olla, a “Shopify for cannabis dispensaries,” that offers an out-of-the-box user-facing checkout and payment experience. Olla’s merchant customers can avoid offering a “guest checkout” experience by making it really easy for their customers to create an account right at the moment of checkout. It’s the best of both worlds: they don’t introduce any extra friction until the customer is ready to checkout, and they’re able to enroll them in loyalty programs and marketing campaigns and save their payment information for smoother checkout and higher conversion.

The beautiful part is that Olla’s use case isn’t one the Stytch team ever anticipated. Invoking the movie Interstellar (one of Reed’s favorites, he’ll tell you more if you sign up for Stytch), Reed explained the philosophical rationale for building API-first:

The reason why flexible API-first companies can be so successful is based on a similar premise: serendipity is one of the most powerful building blocks for developer platforms. You’re exposing helpful primitives to developers so that they can build better products. If you limit yourself to building widgets, it’s still possible to build quite large companies, but you’ll always be limiting the serendipity on your platform and the ability for your customers to discover and enable new useful applications of your technology that you wouldn’t have otherwise predicted.

API-first will win here. If the history of technology acquisitions by public companies is any guide, Auth0 is likely to get slower and less innovative inside of a larger company, not faster.

It’s just a matter of time and survival before Stytch passes Auth0.

Stytch will also to battle for the pure enterprise clients. In my first conversation with Reed and Julianna, they told me that they’ll need to layer on a top-down approach eventually, but that it’s not a core focus for the time being. That said, enterprises are still signing up; in our fireside chat, Reed and Julianna mentioned that users from Fortune 500 companies and big banks were signing up self-serve.

At some point, they’ll need to build out an enterprise sales motion. Twilio’s Jeff Lawson, an API-first, developer-first CEO originally opposed to the idea of sales and account management, changed his tune when Uber unexpectedly moved off of Twilio.

When Stytch does go after enterprises, it will face competition from companies like Transmit Security, a 7-year-old, enterprise-focused, Boston-based company that recently raised a chunky $543 million Series A.

Transmit Security

Like Auth0, Transmit Security is not API-first and is focused on serving a different segment of the market, namely legacy banks. Transmit is worth watching, but not a direct threat.

When we look back in a decade, I think the most important thing will be whether Stytch was able to capture all of the new companies and grow with them, a la Stripe.

On that front, the most direct competition is probably Magic. Magic is also well-funded, having raised $31 million from Northzone, Tiger, Digital Currency Group, Volt and other top firms, along with angels like Naval Ravikant, Adobe’s Scott Belsky, and Dapper Labs’ Roham Gharegozlou.

Magic

Magic is a very legitimate competitor. One differentiator is that Magic seems to be more focused on web3 companies -- it lists Decrypt, Polymarket, and fairmint on its home page -- whereas Stytch hasn’t doubled down on a particular segment. While I’m obviously all-in on web3, larger web2 and enterprise clients may be more attracted to Stytch’s current more neutral stance.

That said, Stytch plans to support web3 projects and apps very soon, with planned MetaMask and Phantom integrations, and APIs that give web3 developers the choice to add both custodial options, like OAuth with trusted providers like Coinbase, FTX, Google, or Apple, and non-custodial options, like wallet sign in. That may serve as an important tool for mainstream adoption.

Ultimately, this battle will come down to who can build out the best suite of products, fastest, and convince the most developers to build with their APIs. I like Stytch’s odds.

I don’t know Magic’s growth, but I do know that Stytch has grown 10x from 350 developers on the platform at the Series A announcement to 3,500 now, just 4 months later. Certainly, Stytch’s new $90 million in funding coupled with its proven ability to hire world-class talent gives it an edge. In the race against Magic, the combination of speed, quality, and relentless focus on the developer will matter.

Why Stytch Wins

The company that I’ve written about that Stytch reminds me the most of is Ramp. The products are different, Ramp isn’t API-first, and it primarily sells to the finance team, so it’s not those things. It’s a combination of velocity and stability that’s very hard to find.

Stytch ships products and hires world-class talent at an alarmingly fast clip, but it never feels like things are out of control. It’s simultaneously ferocious and calm.

That’s a testament to the founders. When I asked Gaurav what most impressed him about Stytch, he told me that each Reed and Julianna “evolve every three months into a new founder.”

First, it was just the two of them, spending six months on research before diving in. Then, they were running a small team of eight high-caliber engineers and designers. Now, they’re thinking like organization builders. Our fireside chat was a lesson in how to think about hiring a world-class team, which they’ve done, and in how to stay ahead of the curve. Now, they’re Series B founders at the helm of a 27-employee unicorn.

Stytch’s Growing Team

And as of today, they’ve made their first acquisition: Cotter.

Cotter did Y Combinator in the winter 2020 batch and built a product that was particularly focused on building passwordless authentication tools for no- and low-code platforms like Webflow and Bubble. After dealing with all of the no- and low-code platforms first-hand, they saw an opportunity to build their own: Typedream (a Not Boring Capital portfolio company).

Julianna and Reed had built a relationship with the Cotter founders, and when they began moving towards Typedream, they started talking about whether it would make sense for Stytch to acquire Cotter’s assets so that the team could focus fully on the new vision.

Reed and Julianna weren’t over-exuberant in their explanation of the acquisition. They thought rationally about what it could do to help Stytch accelerate the product roadmap. Specifically, while they’re not committing to no- and low-code products, the acquisition “has given us a great input into our future roadmap there and simple blueprints for how we might compete in the future in those markets.”

That encapsulates why I’m so bullish on Stytch: deliberation then speed then serendipity.

A bet on Stytch is a bet that offering a wide range of secure modalities in a way that’s frictionless to developers first, and then to those developers’ end-users, is how to acquire the most customers. It’s also a bet that an API-first approach that leaves room for serendipity and emergent use cases will give Stytch the most surface area on the internet. Giving customers the tools to build exactly what they want will ultimately beat monolithic, prescriptive solutions.

Already, Stytch is winning customers away from Auth0 and improving their core businesses. Yesterday, they released a case study on Lighthouse, a next-generation apartment rental platform that switched from Auth0 to Stytch. By going passwordless and creating a mobile-first authentication flow that Lighthouse was able to design to match their users’ actions, the company saw a 62% improvement in its sign up conversion rate.

Examples like that are why Reed and Julianna think that the opportunity is so much bigger than Auth0’s $6.5 billion acquisition. They believe both Auth0 and Okta have dramatically underestimated the market:

Authentication is a huge market and growing quickly, but we think the incumbent companies haven't tapped into a lot of the latent opportunity here, particularly if improved authentication can also improve a company's core business metrics like we've seen passwordless do for our customers.

Building API-first and offering the most complete menu of options, the TL;DR of Stytch’s strategy, means leaving space for customers to uncover all of the latent opportunities on Stytch’s behalf.

As customers uncover those opportunities, Stytch grows. And as Stytch grows, it unlocks the opportunity to go after the really big vision.

The Big Vision

Imagine having a Passport for the Internet.

That’s the vision that Reed and Julianna laid out the first time we spoke back in February: to do for onboarding what Shop Pay has done for checkout.

They could achieve that in a few different ways.

Passively, imagine logging into one account in a product that uses Stytch and automatically logging into any other Stytch-powered site via a recognized device.

Actively, imagine that Stytch builds up the equivalent of a passwordless password manager that picks up all of your authentications in the background and uses that to seamlessly log you into those sites in the future.

In either case, once Stytch adds web3-support, your Stytch Passport could be a fluid way to traverse across the whole internet, web2 and web3.

That would be a magical end-user experience, and it would also be a strong selling point for the next big enterprise client: “Would you like our 50 million users to be able to automatically log in to your site? Oh by the way, when your customers don’t need to think about logging in, we can dramatically improve your conversion and drive top-line growth.” Sold.

With each new client, the network would get stronger, as would the pitch to the next big client, and the one after that, until Stytch wins the internet, and takes a miniscule fee on every log in along the way.

It starts with killing the password, but it ends up much bigger than anyone could imagine.

How did you like this week’s Not Boring? Your feedback helps me make this great.

Thanks for reading and see you on Thursday,

Packy