SFG 38: Julianna Lamb on the future of passwords

​
‍In this episode of the Startup Field Guide podcast, Sandhya Hegde chats with Julianna Lamb, co-founder and CTO of Stytch. Stytch is a comprehensive tool for identity management. Its auth and fraud prevention capabilities improve both security and user experience. Last valued at $1.0B, the company now works with over 1000 customers.

‍
Be sure to check out more Startup Field Guide Podcast episodes on Spotify, Apple, and Youtube. Hosted by Unusual Ventures General Partner Sandhya Hegde (former EVP at Amplitude), the SFG podcast uncovers how the top unicorn founders of today really found product-market fit.

‍

Key takeaways for founders:

• When it comes to marketing to developers, Julianna's team built trust by being authentic and transparent about the technology, product roadmap, and company. Some of Stytch’s best blog content is focused on sharing “behind the scenes at Stytch engineering”. Their first hire was a growth marketer to help scale the audience rather than a content producer.
• Julianna's founding team invested early in word-of-mouth and community, particularly through Twitter. Endorsements are crucial for adoption since developers want to make sure that what they're using for critical infrastructure is going to be solid and reliable, and "they trust people they know or people that they respect.”
• A big product learning for Stytch has been how important it was to make the product extremely easy to integrate and flexible so developers can customize it to their workflows. They now avoid being too prescriptive since developers want to be “able to control the experience."
• Stytch's early positioning was focused on helping devs go "passwordless" which helped them build awareness and mindshare. In your early days, your value prop needs to be different, not just better. However, a lot of their early adopters were stiull using Auth0 or other tools along with Stytch because they weren't ready to stop offering their customers this option. As Stytch started scaling, they included traditional password management in their product offering and pivoted to a broader identity management tool.
  

‍

‍

Episode transcript

‍

Sandhya Hegde

Welcome to the Startup Field Guide, where we learn from successful founders of unicorn startups, how their companies truly found product market fit. I'm your host Sandhya Hegde, and today we'll be diving into the story of Stytch. So Stytch is a comprehensive tool for identity management. Its auth and fraud prevention capabilities improve both security and user experience.

Last valued at over a billion dollars, the company now works with over a thousand customers in the identity management space. So joining us today is Julianna Lamb, CTO and co-founder of Stytch. Welcome to the Field Guide, Julianna. Before we dive into the story of Stytch itself, I would love to hear how you view the evolution of identity management, especially from the developer perspective.

Most of us here have experienced the frustration of managing passwords and then SSO and then multi-factor authentication. And, it just gets perhaps more secure question mark, but definitely worse in terms of user experience over time. But I'm curious what the developer view of this evolution has been over the past couple of decades and how that informed the birth of Stytch.

Julianna Lamb

Yeah. So I think authentication was basically username-password for many, many decades, right? And then I think you start to see like 10, 15 years ago there start to be new, innovations in terms of things like multi factor authentication. You have companies like Twilio making it really easy to do SMS OTPs and start to see more different ways of doing authentication start to take on. And then I think as that sort of started to change and there was this like proliferation of different ways of doing auth, people were trying to manage that and navigate what do I use when, how do I use these different options from like email magic links, the social logins with sign in with Facebook and Google.

You start to see some of the more workforce oriented solutions like time-based one time passcodes with Google Authenticator app and those types. FIDO starts to establish more industry wide standards and protocols for things like WebAuthn, and now most recently, passkeys. And I think that's just a ton of innovation that's happened in a pretty short amount of time. And like you were talking about, so much of this is like, how do you actually make it possible for users to log in, not shoot themselves in the foot by taking a bunch of shortcuts and, using password123 across all their accounts when they have hundreds of different online accounts that they have to manage. And then how do you help them increase security with things like two factor or going fully passwordless in some cases as well. And so I think what we found is that just really hard to figure out what you should be using, how you should be using it, depending on the type of application you're building, what your user demographic looks like, what type of data you're protecting and also knowing that this is rapidly evolving. I think.

When you were just building username password you get your hashing algorithm, you store some passwords in your database, and you're pretty much good to go, but now we're seeing the sort of pace of innovation happen much more quickly where you as a developer now need to keep up with that, right?

Pass keys, launches, and you need to be able to support that and probably want to support that because I think it is an example of something that is a pretty seamless user experience in a lot of cases and provides really good security, but now you have to dedicate a bunch of engineering time and effort to staying on top of these trends, building out these new authentication features as they're coming to market and I think that really changes the sort of calculus of, is authentication something I should build or is this something that I should buy from a vendor? And so that was some of the initial reasoning behind starting Stytch is, I built authentication in previous roles. My co founder was a PM on an authentication team and was dealing with a bunch of this. And we were just like, this is really hard to build. And this is really frustrating. And we don't feel like there's a tool out there that makes it easy from a developer experience to build really smooth authentication experiences.

Sandhya Hegde

Got it. And, I know you, your founding team all met at Plaid as well, perhaps, and which was very much an API first company. So can you share more about that? How did that kind of inform the product vision and kind of the founding insight for Stytch?

Julianna Lamb

Yeah, definitely. I think our experience at Plaid was really interesting in that not only is Plaid an API and developer company but they're also basically just building login to your bank as a service. How do you connect to your bank account? And we saw login experiences at really large scale across the 10, 000 different banks that Plaid integrates with. We also saw that evolving from going from a traditional username password experience to more OAuth connections and saw the sort of rapid innovation that was happening in that space as well. And so I think some of the initial kind of frustrations that we saw with the current market for building authentication, whether it was either very bare bones, or you're building it entirely in house, or extremely opinionated widget that you're dropping into your application. And I think one of the learnings we had from Plaid, and being really developer focused there, is that developers want something that's easy to integrate, but they also want to be able to control the experience, and have flexibility in terms of what they're building, and what it looks like in their application, can they customize things so that their unique, branding and user experience comes through? 

And so that was really critical for us when we were starting Stytch is building something that was very flexible and customizable, but still easy to use from a developer experience perspective. I think you can go way too far on the flexibility side and build something that doesn't actually help you that much because you have to figure out everything anyway, and you might as well just build it in house, so I think that's consistently an important sort of line that we tow in terms of flexibility, but also being opinionated and giving you good guardrails out of the box.

Sandhya Hegde

 Makes sense. Moving to the first few months of the company. Now, you were your own customer, so you had a lot of authenticity around the problem. How did you approach validating the idea you had around how this should work, what the developer experience should be, it's not just what you wanted, but what a broader market wants it. What was your process of picking a customer segment, figuring out what is the minimum viable product that actually gets them excited enough to choose a vendor as opposed to continue with whoever they have, or, continue building in house, perhaps?

Julianna Lamb

Yeah, so my co founder and I first had this conversation. And we were like, this is wild. Like we're both building authentication in house. I had worked on some fraud detection and prevention at Plaid. And then I'd gone to another company called Very Good Security. And I was working on basically ripping out Auth0 and replacing it with an in-house solution built on top of some open source technology.

Reid was still at Plaid working on the authentication experiences team. And so we're like, okay, we've seen this from a bunch of different angles. We feel like this is a really big problem. What are we missing? How is there not a more sort of like modern really developer-friendly authentication vendor out there?

Surely we're just missing something. We can't have that unique of an insight. And so it took a lot of convincing of ourselves to basically be like, is this something that broadly resonates in the market? Are we just uniquely seeing these problems or is this something that is a real pain point across a lot of different types of companies? And so I think we started with a fairly broad lens in terms of what types of industries or types of customers we wanted to be able to serve. And I think we continue to have that broad lens today. The idea is basically that there's so many different types of companies and applications that need login.

Can we build something that is really broadly applicable because at the end of the day it doesn't look that different If it's your bank you're logging into, if it's a social media app you're logging into, if it's a B2B SaaS company, there's definitely some differences, but It's not like a different universe of problems. And so the way that we approached it was basically just trying to talk to as many people as we could. And we had the benefit of this happening at the very start of COVID when everyone was sitting at home with nothing to do. And so we were like, hey, you want to get on a Zoom call and talk to us about authentication?

And we had a lot of people take us up on that. And at each conversation, we just kept hearing more and more frustration with whatever people were using for authentication today, whether that be in house or using an existing vendor. And then if people were excited about it, we'd ask them, is there anyone else that you think might have some interesting perspective for us and just snowballed from there in terms of the number of people we were able to talk to and the amount of excitement for something better in the space is really what got us to conviction that this was a problem worth tackling.

Sandhya Hegde

Got it. And how did you figure out what's the intensity of the problem? How much money is being spent on it? Is there revenue being lost because of it? Like, how did you put a business lens around just the developer pain?

Julianna Lamb

Yeah, so I think we did just some napkin math in terms of existing vendors. So Auth0 was and is a really big player in the space. So we were able to look at that and say, okay, they've built a really solid business around this and we think we can build things in a way that would resonate maybe more for the market today versus the market 10 years ago when they were founded.

And then looking at things like the cloud provider. So there's AWS Cognito, Google Firebase, et cetera. It's okay, there's definitely a lot of money being spent in this space. Do we think that we can not only maybe go after that existing spend, but could we build something that could convince people who are typically building in house to actually move to a vendor.

And I think that was the thing that got us really excited is that we felt like we had wanted to use a vendor in previous companies and then had ended up building in house because we didn't find the solution we wanted. And a lot of it came down to just that sort of flexibility of experience and like how powerful the APIs were that we were able to integrate with. And so we had this hypothesis that we were those target customers. And we thought that there were a lot of other people out there that would have similar frustrations and pain points and had chosen to build in house, but would maybe go with a vendor in the future.

We didn't do anything super scientific in terms of trying to quantify that. And I think in part, because we knew that there was a lot of existing spend. And so we were like, okay, we can go after that, but we also want to be thinking about like how we're building something that can continue to expand that market over time.

Sandhya Hegde

And is there a particular industry like, FinTech or ecommerce that you had more early success with? Who are some of the maybe very early adopters that helped you shape the developer experience, the product and the first year of the company?

Julianna Lamb

Yeah. So I think coming from Plaid, we had a lot of experience with FinTech. We'd worked with a bunch of Plaid's customers and knew the FinTech startup ecosystem well, and so I think we started with a hypothesis that might be an interesting sort of initial vertical for us. But we also started from the beginning trying to be pretty broad and not narrow in too much.nAnd so I think that informed some of how we thought about product roadmap.

But we also wanted to make sure that we were building something that anyone could use. And so we tried not to get too specific really early on. I think this is also something that I think you can succeed doing this a bunch of different ways. So we didn't really have early design partners. We basically built a beta version of our product. And wanted to launch it as self serve so that we could see, Okay, who does this resonate for? And then go from there. And I think what we found when we actually launched is that a lot of our initial customers that are still thriving with us today ended up being a little bit more in the B2B SaaS space, which I don't think was going in something that we anticipated being like, maybe the biggest vertical to begin with. And I think we've continued to see that pull over time to the point where we now have a dedicated B2B offering that's distinct from our consumer offering and we've continued to see really broad types of companies, everything from Crypto to healthcare you name.

And so I do think that initial approach of being pretty broad has ended up panning out how we wanted it to, but I think there were some definitely surprises along the way. You build something that you think is broadly applicable and put it on the internet and see who shows up.

Sandhya Hegde

Makes sense. And what about from more surprises on the product side? Were there any patterns in terms of, the feature requests you were getting, that were aha moments for you as the founders?

Julianna Lamb

So the reason we started passwordless is that we found that trying to manage all of those passwords was annoying from like a user experience perspective, but also really bad from a security perspective as well. I worked a bunch on fraud detection and prevention at Plaid that was basically protecting against credential stuffing attacks. So people take stolen passwords and try and see if they can get access to some other account where that person has reused the same password. So we're basically like Passwords are the worst. They need to go away. We think that there's a lot of interesting companies that are going passwordless. We want to be the default vendor if you're trying to go passwordless. So we spent probably the first year and a half of the company as fully passwordless. And we definitely had some success with that. We saw a lot of people that wanted to go fully passwordless using us.

We also saw people putting us in side by side with another authentication option as the passwordless option. But we kept having people come to us and be like so excited about passwordless. You guys support passwords too, right? And we were like, no we're passwordless. What are you talking about?

And what we learned through that experience is that even though people were really excited to go passwordless, they didn't feel like all of their users and their business were ready to go 100 percent passwordless. They still felt like there was some need for offering that password option. And so we ended up building passwords.

And that has been a really pivotal moment. I think in terms of the momentum we've seen. I think we're just able to serve a much broader base of customers and really be that like comprehensive auth solution for them, not just a point solution. But I think that's something that we didn't really anticipate and probably ignored some of those feature requests for a little too long, because we were dogmatic about passwordless is obviously the future if you're not on board with that you're probably just not a good customer for us. But what we found is that when people offer those options, majority of users are using passwordless options when given the choice but there's maybe that 5 10 percent of users that, that really love their passwords and you have to satisfy them.

Sandhya Hegde

And I think what's really interesting, I think I see this a lot in developer tools and developer infrastructures. The definition of focus usually, enterprise software means you're focused on a very particular problem or you're very focused on a particular industry, right, which shapes your product vision. But when you're working, when the definition of your problem is, something like identity, which is so broad and your customers cannot afford to say no to to their end users, right? The right strategy feels like your focus cannot be around a particular industry or a particular piece of the product. Your focus is on a particular set of developers, right? Which is, you have to build everything this particular set of developers want. And they're the developers who are saying, I want like something modern, which gives my end users all these different options. As opposed to I, as a developer, I'm going to be dogmatic about how you log into my applications. It's almost like your focus is a particular developer persona, but then you have to build everything that they need as fast as you can.

Julianna Lamb

Yeah, definitely. I think that's been a really interesting learning is just how many features we've had to build to be able to really compete in all of the deals that we want to be competitive in. And I think it's because Auth is a very broad space. And if you need a specific thing, in most cases you, you need that specific thing. There's not too many workarounds. And so I think having that broad base is really important. And then it's like, how do you go and really differentiate and resonate with that target developer,and not just check the boxes for them, but how do you build a solution that they get excited about so that they're willing to maybe migrate from whatever they're using today. That can be a big upfront cost, right? And it's not just checking the boxes. It's also like really building something that people are excited about. And I think that kind of powerful modern tool tends to be the thing that gets people excited.

Sandhya Hegde

That's a good segue to maybe developer marketing, which is one of my favorite go-to-market topics. I feel like if I try and recall the early days of Stytch, it was definitely the fact that you were talking about going passwordless that made you stand out. And, perhaps that is also what drove a lot of developer awareness in the early days. But of course that's not, necessarily the product a couple of years later but probably helped you stand out in the beginning, I'm curious, what have you built and learned about developer marketing over the past few years? What has worked and what has not worked at Stytch?

Julianna Lamb

Yeah, definitely. I think you're right that having that really strong kind of brand voice around passwordless early on I think helped us stand out, resonate, also I think just like showing people that we were being really intentional about what we were building, had an opinion about what the authentication market looked like, and I think that has enabled us to continue to grow and expand what our product offering looks like while still, I think, trying to stay pretty true to that authenticity, but also sophistication and kind of opinionation around what is auth?

What should you be building? How should you build it? And so I think some of the things that have worked the best for us are, I think, just being very authentic and talking about what we're doing, not just talking about the products that we're building, but how we're building them. Doing things like giving you a look behind the scenes in terms of how we build the company or how our engineering team works. Some of our best blog content has been just behind the scenes engineering content. And I think that it can be really powerful for an infrastructure company because really what you're selling is trust in us to be able to provide reliable authentication and I think the way you build trust with engineers is just like showing them how it works and giving them that information so that they can make that judgment themselves.

I think anything that's too oh, we're the best and most powerful, I'm going to be skeptical of that too, right? How do you show, not tell what your strengths are? And so I think that's something that we really try and lean into is just being really transparent about how we're building, what we're doing that's interesting, why we think certain authentication methods are good for different use cases, how we build those products to be really reliable, all of those things.

Sandhya Hegde

 Got it. And especially for the first year when you were still a really small team, how did you approach developer awareness as founders? Like, how much of your time was, figuring out how to keep growing your awareness, your developer community? And, what do you do as founders versus how do you figure out, okay, now I'm going to hire someone to scale this, especially I think with developer marketing, it's really hard to hire non technical people to scale that function.

So I'm curious if go back to I don't know, early 2021, how were you approaching that?

Julianna Lamb

Yeah, I think we focused a lot on just organic word of mouth and some social content, primarily on Twitter. I don't think like what we were doing on Twitter was intentionally marketing either. I think Reid and I both just enjoy being on Twitter and talking about what we're doing. I would tweet a lot about just Founder things. And so I feel like that was really valuable in terms of helping to scale that word of mouth. It was just like off-the-cuff tweets. There was no strategy. And I think that worked pretty well. I think even today, a lot of how we think about marketing is like scaling word of mouth, because I do think that engineers in a lot of cases want to make sure that what they're using for critical infrastructure is going to be solid and reliable, and they trust people they know or people that they respect, even if they aren't friends with them directly about which tools to use. And I think that's something that, that we try and lean into. 

We obviously do a lot of SEO and Google paid ads and all of that because there's going to be people that have a really acute problem and they're searching for a solution for it and you have to make sure that you're showing up there. So I think by the time we had a self serve product that we had some solid traction on, we have launched customers, we're like, okay this works we're able to serve people, we think that the self-serve experience of getting started is good enough that if somebody just finds us on the internet, that they can integrate and go live and it's a high quality experience.

Now it's probably time to start thinking about marketing, and so the first marketing hire that we had was focused more on kind of growth marketing because I think that is something that in a lot of ways is like a science, and you know how to do it, you know how to optimize for various things, you have to have some ability, for sure, to be able to get into the details, to understand, where are developers gonna be, how do you talk to those developers. And I think my co founder and I felt like we were good enough at some of the storytelling and what we really needed was someone who was more an expert in kind of the the science of marketing. And so I think that was probably the right early hire. I think since then we've definitely focused too on building out our technical content team that is able to write really technical content themselves, but also work with our engineering team to help produce some of those kind of behind the scenes blog content that is valuable from the search perspective and SEO, but I think is also the type of thing that like we've had some go viral on like Hacker News and that can be really powerful too.

And so I think our marketing team definitely skews more technical and I think they just have to at acompany that's selling to developers.

Sandhya Hegde

 And, I think TLDR I really love the fact that A, how much you two as founders were involved in making sure you built that word of mouth. I think that's something you just cannot delegate. That is the first couple of years, that's the heart of the company. And I also love that your early messaging was about how this is different, not better, it was passwordless as opposed to better passwords. I think those are really crucial decisions that you made so well. Going back to when you started was a really interesting time. I think the first set of lockdowns had already happened before you started the company during a pandemic, there was a big bull market just starting to take off in terms of capital, especially venture capital, but public markets as well. I'm curious, looking back to those years now how do you think that impacted Stytch as a startup? The fact that you started at a time when almost everything was the opposite of what you would expect when a typical company starts, there's way too much capital available, but also you can't meet people in person, the opposite of every startup founding experience leading up to 2020.

Julianna Lamb

Yeah, definitely. I think certainly an atypical experience in terms of a lot of different things. I have only fundraised on Zoom. I never have done a pitch in person and I don't know what that'll be like. Maybe one day we'll do that. Who knows? We didn't meet Chetan who led our seed round. So he did our seed round in June 2020 and I don't think we met him in person for almost a full year until after vaccines in like spring 2021. And he played such a pivotal role in starting, helping us start the company and then was on our board and we're doing these monthly zooms, right? And you get to know him really well, but you've never met him in person. Such a wild experience. For our early hires, we ended up hiring, I think our first 5 engineers all in San Francisco. We didn't exactly intend to do that, but we were pretty intentional that we were going to have an office as soon as we could. But given everyone was working from home and in summer 2020, when we were hiring who knew when we were going to be able to go back to an office? We were open to hiring remote, but just so happened that those first five were all in SF. And so what we did do was we would go and drop off laptops and some Stytch swag for people's first day so that we could meet them in person.

We'd have masks on and be outside, handing over the laptop, but we thought it was really important to try and build that connection. If we could with people, especially these first 5 engineers that are going to be super pivotal for the culture, the company and all of that. I think what was valuable in terms of the market and we were able to fundraise and do so to a degree where we're able to focus on just building and scaling the product without having to think about fundraising for the foreseeable future, I think that has enabled us to be really intentional about the foundation that we built and build a really comprehensive suite of products. And I think we were fortunate that when we started, we had a pretty strong idea of what we were building. Obviously, it's evolved in a lot of ways, but we knew we were building an authentication platform that was for developers, flexible, easy to integrate. And we knew we needed resources to go after that. I think there's some types of products that you maybe ship an MVP, test it out, pivot, iterate a bunch. And that sort of wasn't the case for us. We were like, we have all of this stuff we need to do. We just need people and time to go and do it.

And so I think that matched up well with the funding environment where we were able to fundraise and then just focus on building the product. And I think that's been really valuable for us. I definitely think that we've continued to hire throughout the U. S. I'm in our San Francisco office right now. We have a New York office now, too. I think because we had to start pretty fully remote, we've been really intentional about how we communicate, how we build culture, all of those things from day one, that I think in some ways it's definitely taken more time to have to do that in a more remote environment that I think naturally happens if you're an early small team all in the office together, a lot just happens naturally. Whereas I think we've had to be more intentional about setting culture, finding the right touch points for everyone at the company to connect and all of that. That I think has enabled us to scale from like the very small team to the 60 plus person team that we have today more efficiently because I think at 60 people you have to figure out some of that stuff anyway And we were just forced to figure it out at five people instead

Sandhya Hegde

Makes sense. So maybe coming to 2024, obviously there's going to be much more adoption of modern AI tools from developers. And there's already been a ton of conversation around the ramifications on security, I'm curious, how has this environment been impacting the roadmap at Stytch or perhaps your customers’ roadmaps?

What's the conversation around AI at Stytch right now?

Julianna Lamb

So I think there's two angles that we're thinking a lot about this from. The first angle is just from a sort of security perspective, I think generative AI is makes it a lot easier for people to run super sophisticated attacks. I think you see this with spear-phishing attacks where people are using voice impersonation to pretend to be an IT help desk or whatever calling you and asking for your one time passcode, right? And so I think it just gets so much easier to run those really sophisticated attacks that companies are going to need to start really investing in making sure that their authentication is unphishable So using things like hardware keys, biometrics, all of those things to help protect people's accounts.Because I think we're just going to see and already are seeing a big increase in fraud and abuse from making it so much easier with generative AI to run those sophisticated attacks. 

And then I think the other angle that we see a lot from is AI companies that are building really valuable tools that cost a lot of money for them to run, getting abused by people trying to take advantage of their capabilities. Maybe you have a free trial that you can use a product and under the hood, they're using OpenAI or someone else's APIs, each of those API calls is quite expensive. And so if you get people abusing that free tier, that can run a really large bill for some of these AI companies. And so we see a lot of people really having to lean into fraud detection and abuse prevention, even as very early stage startups.

And so I think one of the hypotheses that we have with Stytch is that the future of authentication is going to be fraud detection and prevention coupled with authentication because it's going to be even more important to identify when someone's trying to log into an application, is this my actual user? Is this someone pretending to be my user? Is this an abusive user who's been taking advantage of the platform with other accounts that they're now spinning up more and more of? Is this a bot that is trying to take advantage of this platform? And so really coupling those together is something that we're leaning into right now in terms of building in that fraud detection and prevention out of the box with authentication.

Sandhya Hegde

And, it feels there'll be a lot more developers trying to figure out how to keep the user experience simple while making their products much more secure. That's the challenge that you're in a great position to support them with.

Julianna Lamb

Yeah, definitely. I think one example of that is that I think GPT 4 can pretty reliably solve CAPTCHA. And so CAPTCHA is super frustrating as a user, but it's now pretty trivial to solve. And so that's like not really doing that much. And so I think people are going to need to really evolve their strategies because thingsthat worked even a year ago don't work anymore.

Sandhya Hedge

Awesome. Maybe to wrap things up, Julianna, do you have any advice for, engineers thinking about starting a company in this environment? What were some of your lessons as a founder? And what advice would you give people thinking of starting maybe a company in the dev tool space?

Julianna Lamb

 Yeah, I think what worked really well for me is keeping a very open mind and being intentional that I was interested in starting a company, but also being really patient and not trying to rush into something, both in terms of, I think, deciding to start a company with a co-founder and also the type of product that I wanted to work on.

I think for probably a year to two years before actually starting the company, I was pretty vocal with people that I maybe want to start a company one day. This is how I'm thinking about it. And just would talk to coworkers and friends, and wasn't really trying to do anything in that moment, but just exploring, keeping my eyes open and being intentional that it's something that I'm interested in so that when the right opportunity came up, I was like ready to take that leap.

But then I think I was also really patient and there were definitely opportunities before to start a company or join a really early founding team on something and, none of those were I think the right idea or people to work with. And so I'm really happy that I took the time because I think now this is something that I'm really excited, going on year four of building, hopefully get to build this for the next 10 plus years.

And I think so much of being a founder and being a successful founder is just showing up every day and really having that grit and perseverance. I think it can be really easy to get excited about something for a short period of time but is this really something that you're going to be excited to show up for the next 10 plus years? And I think making that right decision is the most important thing.

‍

​