Monetizing SaaS: Episode 45 with Jeff Escalante, Engineering Director, Clerk.com

Jeff, thank you so much for being a part of the podcast. I've gotten to know you over the last year and it's been so much fun getting to know you. You have had such a cool career. I mean, you studied neuroscience at Hamilton College, which I actually used to play soccer against, so I know the school well. And you've traveled all over the world and you've been an engineering manager at a number of just incredibly impressive companies, HashiCorp, Vercel, now Clerk. I'd love to hear your story in your own words. How did we get to now?

Yeah, sure. I'll try to give a brief version of it up front and then, you know, if you have any further things you want to dig into, we can do that. It's been many years of a career, so I don't want to take too long. But let's see, I kind of started out doing like graphic design-ish stuff in high school and got really interested in that. Just found a lot of use for graphic design. Ended up just pulling out Photoshop constantly, whether it was for posters or t-shirts or cards or like whatever, it just was useful. And so I ended up doing a lot. I sort of started freelancing, doing graphic design throughout college. Eventually someone asked me to make a website and my rule of life is if someone asks me to do something that sounds interesting or crazy, I usually say yes, even if I have no idea how to do it. So I was like, yeah, of course, make you a website. I had no idea how to make a website. So I kind of figured that out over a summer break and put together something that was pretty terrible, but it looked nice because I was decently good at graphic design at that point. And then sort of ended up with a bunch more web development, like freelance jobs throughout college. As you mentioned, I studied neuroscience. It was cool. It was interesting. But the kind of career paths that led out for that, like, weren't super compelling to me. And I really enjoyed doing tech work. I had been doing it sort of on my own on the side. 'If someone would pay me for this full-time, that would be awesome.' So I put together a little portfolio and applied for a bunch of internships because I had never had any professional experience or academic training whatsoever in design or, or programming other than one course that I took when I was studying abroad in Costa Rica, Intro to Java. I got an F, so it wasn't a good look, but I tried really hard and I landed an internship at this agency in New York. I would imagine pure luck, which was wonderful. So I moved to New York after college and I worked at this agency for a while. Great experience. I mean, agencies just kind of get projects in and out all the time. So I got exposed to a wide variety of different sorts of like languages and tools and architectures and mistakes don't stick with you quite as long when you're kind of working on ephemeral projects as when you're working on a product. So I honestly, I think it was a super good learning opportunity and I, I do recommend for anyone starting out their career to at least look at a few agencies because it's a cool place to sort of like spread your wings and learn. Um, I was there for a long, long time, really enjoyed it. Uh, eventually that company sort of, uh, went down the tubes and Asha Corp was one of our customers. And around that same time, again, I think by, by pure luck, I'd been doing work for them and they were like, hey, we like your work, we want to offer you a job. And I ended up moving over there and that was a great company, super great. I learned a lot there. I was there there for about 4 years, and just about at the end of my time was the time when HashiCorp went public, which is really cool experience to have being at a company that kind of grew. I started around like maybe 200 employees, and by the time I left, it was over 1,000, and they were public, which is really, really wild of a journey. Super grateful to that company and all the folks there for the time I got to spend there and what I got to learn, especially also being kind of a developer tool on an open source tool. It was really, really neat to see that happen. At the end of my time there, I ended up getting an offer to go manage the Next.js team at Vercel, which was totally a dream job for me. I'd been using Next.js from early, early on. We had adopted it at HashiCorp super early and we'd been really close to the team collaborating on kind of like architecture decisions. We'd made a bunch of contributions to it. So I was, I was very familiar with the tool. It was something that had provided a lot of value for us. So it was really cool to head over there. Great people, had a great time again, learned a lot and ended up moving to Clerk maybe like a year and a half ago or so, which is a whole nother long story on its own, but has been absolutely fabulous. I'm absolutely loving it at Clerk right now. Whenever anyone asks me how it's going, like, couldn't ask for anything more. It's been, it's been amazing.

That's awesome. Thank you for this.

Yeah, I feel super lucky to have had this kind of like series of opportunities to learn things and experience companies that were making cool stuff and growing. Yeah, absolutely.

Yeah. And, and it's some very interesting sort of like growth phases, growth stages, kind of inflection points in their own cycles. I want to talk more about Cleric, but before we go there, go back to HashiCorp for a minute, like 200 employees to over 1,000 employees and an IPO. You know, when you kind of look back on that experience, I'm curious, you know, if there are 1, 2, or 3 lessons that stand out to you. It's like they were the key lessons of that experience.

Yeah, I mean, there's a lot. I'll kind of just pull out some things off the top. I like, I guess the first thing I started thinking about when I, when I came onto that company was that it was clear that the company was like growing quickly and scaling quickly. And that, that wasn't going to probably stop. And I came on to a kind of like form a new team that was responsible for all the like websites and, like public-facing, like presence of the, of the company as well as like docs and things like that, which were previously sort of just distributed as side projects, throughout the company from engineers that were like working on the product, which is really interesting. So we sort of had an opportunity to like both go to these teams and like orchestrate a handoff of something that they've been working on in a way that needed to be done not causing drama or strife and be like, hopefully this is a helpful thing, which was definitely an interesting process and a challenge. Ended up working out, which is great.

Did that stand out to you because of what it taught you about like communication and human psychology?

Sort of. I mean, I hadn't really been involved too much in like management or leadership before HashiCorp. I, uh, just been doing IC work. Um, and so being just thrust right into that position of like, hey, here's a new team, like you're at the beginning of the team, you've got to hire people and then manage them and also like orchestrate this like kind of like careful political process of like swapping pieces of ownership between like, you know, 8 different teams within the company. It was like definitely cool, a little bit scary for sure. It wasn't without its like bumps at the time, which, you know, happy to get into more if you want. But that was sort of one part of things, just like considering how to tackle that and figuring out how to do it. And the other part was kind of figuring out now that we've absorbed all these things, what are we going to do with them? You know, they were, they had each kind of started in the same rough template, but as different teams took ownership over them, they like moved in their own directions. And so they all had like unique traits that were there for a good reason. But part of our purview is like, we can be more efficient since these things are mostly the same between all the different products. And for anyone not familiar with HashiCorp, HashiCorp has like 6+ different products that they offer under the same company. The products are related, but ultimately they're like different. And each one of them has its own like brand and like docs and website and like presence within the community. And so part of the purview was like, we also wanted to find the common abstractions between them and not continue like repeating ourselves. And then another part of it was knowing that the company was scaling up. I wanted to make sure we were prepared for that sort of inevitability at the time. They were all a set of static websites that were built using a generator called Middleman, if anyone remembers that. Uh, who's listening, shout out to you. Cause it's, it's a throwback. It was sort of like a static site generator version of Ruby on Rails.

Interesting.

So it was written with Ruby. It used the Rails asset pipeline. It sort of like lived in the spirit of Ruby on Rails, but instead of producing a server rendered website, it would produce a static file output. But that was sort of unmaintained. It was a bit out of date. The version they were using was several major versions behind. So it was inevitable that we needed to make some upgrades and touch-ups just like regardless of the situation that needed to happen. And then the further question was like, in what direction do we take that? And how do we think about how to do this in the midst of a rapidly scaling company? We don't want to overengineer it because we still need to be moving quickly. We don't want to overcomplicate things. But also we don't want to say like, let's just solve the problem that's straight in front of us. And 6 months down the road, we've got to wipe the whole thing and re-architect it again because that's even less efficient. So that was like a really interesting sort of like technical challenge and balance to manage that I feel like I learned a lot from.

It's a great story and we'll come to this later, but I am curious. I mean, you know, one of the things that we often talk about on this podcast is just how challenging it is for companies to evolve pricing and packaging as they pursue multi-product journeys.

Sure. Cool.

I'm curious if you ran into any of that challenge while at HashiCorp or if that was sort of not—

Yeah.

You at the time.

It wasn't, but I was involved enough in things to sort of have some pricing and packaging thoughts for you.

You saw it from a distance, at least.

Yeah. I think so. The interesting thing about HashiCorp in general is that they are a free open source tool with an enterprise product offering. So the choices that you had when you were adopting HashiCorp were you paid zero or you pay an obscenely large amount of money. Generally, there was like no middle ground. I mean, you weren't going to get in the door with less than like $50,000, $100,000 a year plan if you were paying HashiCorp. Whereas having the other end of the spectrum be you pay nothing, it's kind of crazy. But that was sort of like how their business model was. It was like, you pick up the open source software, you try it out. If that works for your developers, it works for your company, it'll last you a good, good long time without having to pay a dime to HashiCorp. And then at a certain point, you get to this company scale tipping point that I'm sure you're quite familiar with, where like, you got to start bringing on some more security people, you got to start bringing on a general counsel, you've gotta start buttoning things up. If your site goes down, you might be losing millions of dollars. Like, and you're like, okay, it's time to start shelling out some cash to make sure that we are stable. We're not gonna get sued. Our site's not gonna get down. We're not gonna drop our big important customers that are funding our company. And you start thinking about clicking on the contact sales button on vendor websites rather than the sign up to try our free demo button. And that was sort of like the clean break that you had with HashiCorp is like once you hit that point in your scale journey, you'd go to HashiCorp, you'd pay the piper, and you'd say, hey, look, these tools have saved us a lot of time. They've created a lot of value for our company. We've already adopted them. We've already deployed them. We now want some more guarantees around security and support and guidance along the path to make sure everything is on the rails, which is really quite interesting. I'll pause for a second in case you have any follow-ups on that. I have more though, if you want.

Keep going. Keep going.

So, so the other interesting piece about HashiCorp was that it was not SaaS. At all. So like you download the thing as a binary, you install it on your server, and it's up to you how you want to do your thing. And it was definitely a good thing for HashiCorp financially, the way that they planned out these like packages, because anybody who paid HashiCorp tend to pay a lot, and anyone who paid HashiCorp tended to already have the product so deeply embedded that they didn't really have any other choice at that point. So that served the company well. The challenge was, one, there's no middle ground as we talked about. And two, when you are picking up a piece of software, paying for it, and then hosting it on your own, there are a million ways that you can misconfigure your environment or the software or anything that surrounds the software. And it brings down your entire website and causes an utter panic. And then you come running back to HashiCorp and say, you know, everything's broken. Like, what am I going to do? What am I going to do? And the company is very limited limited in its ability to actually help you because HashiCorp doesn't have access to your servers. They didn't set them up. They don't know how they're configured. It wouldn't make sense for the company to have access to those things because they, they're your company's like private servers and infrastructure setup. And so it could be very, very challenging to figure out what problems people are running into. And usually the problems they're running into were their own problems that they caused because of the way they set things up and not problems with the product. But it was really hard for companies to tell the difference between that because, you know, Terraform was failing. And so something must be awry with HashiCorp. So you go to HashiCorp about it. And so that was kind of this constant, like, challenge and, and pain point for the company was that, like, because of the fact that you self-hosted, that was the only way to do it. It was really, really challenging to work out problems that people had with it. And there were a lot of problems that people had with it that, again, were like, had absolutely nothing to do with the product and there was nothing the company could do to fix them. But when they happened, it still felt for the customers like this was something that was on HashiCorp.

Yeah. It's a really fascinating challenge and you kind of described two challenges. One, there's the lack of middle ground. And then the other is we can't go support the customer when, when there's an issue. On the middle ground piece, was that actually a problem that the business perceived mattered or was the business model working so well that you know, like it was sort of just incremental opportunity that was never really kind of viewed as a mission-critical problem or opportunity to address?

I think it was a little bit of pieces of both, and I think a little bit of pieces of both of the two challenges I just talked about weighed into HashiCorp's decision to actually invest in a SaaS product, which they do now have. Partially it was because there was no middle ground, and there were companies that were sitting in the middle of those two were like, they were using the product, they wanted to get some support, they wanted to get some guarantees, they wanted to get some premium features. They didn't want to shell out $100K+ a year because that wasn't in their budget at the company size, and they were kind of out to dry. Was that like a huge problem financially for the company? No, not really. They had enough big customers that were paying them enough that it wasn't like that lost opportunity was enough to be like a substantial issue. But when you combine it with the other problem, which is that like we can't ensure that you've set up your infrastructure properly and that leads to a lot of problems. Those two together were enough from at least where I was sitting, which was not in the executive suite, to be clear. So I don't actually know the answers to this, but this is sort of what I saw. Those, those two together were enough to drive a decision to say, hey, I think this is actually worth investing in because that got both of them out the window, right? One, we hosted it, we could be sure that it was hosted right. We could solve your problems. We could make sure it didn't go down. And two, it covers that ground appropriately. Yeah.

I was totally unfamiliar with that story around how HashiCorp, why HashiCorp pursued SaaS. So that's fascinating.

Super, super interesting for me and like a big, a big learning for me across my whole career. And I've always sort of worked in dev tools and I've always seen this split between companies that will chase enterprise and that will chase like being a developer darling product. And HashiCorp was so interesting in that it kind of did both, but it did them in completely separate spheres. You know, like it was a beloved product by developers. It was free. It was open source. Those are things that create more developer love, you know, because one, we're cheap and because two, we like open source. But also they had this massive purely enterprise sales business going on. And this was actually something that like it took me a really long time to like get a handle on and understand it because of the way that HashiCorp presented itself as a business. Like if you went to HashiCorp's website and maybe if you still do today, I don't know, I haven't checked it recently. It's like, as a developer, it's complete nonsense. You know, it's like a bunch of white papers, a bunch of like jargon terms that like don't make any sense and don't mean anything. You'd go to the website and you'd be like, what is the product? And you'd scroll the whole thing and read the whole thing and get to the bottom and be like, I still have absolutely no idea what this product is. No idea. Right. And this always frustrated me because I was like, look, like this is where the top of our funnel sits. Like we. Get foot in the door on these enterprise deals by virtue of developers using and implementing these products within companies. And it's crazy to me that like all of our, all the content for our sites is like effectively hostile to developers because you read it and you'd be like, honestly, it's kind of like, it sounds like a bunch of bullshit. And I would complain about this a lot and people would get mad at me for doing so. At that time, the reason was because I was just like, What is, what is this content? Who reads this and gets anything out of it? Like, can't we just describe what this product is in plain English? And that would be more effective. Like, is the person who's writing this content like incompetent? They're like, no, no, like this is what we need. Like, this is what the customers want. I was like, I don't know, you know, like, are you sure? And at one point I was at an event, like an on-site event with the company and I was talking to someone who was in sales and I was like, what do you like, what do you think about the website? Like, do your, Do you send your customers to the website? Do they see it? Do they like come in that way? Do they read things on there? Is this like something that makes sense to them and like is good? Or are we just like spitting out jargon and like kind of dropping the ball on a great opportunity to market to human beings? And he was like, oh yeah, they love it. Like all of those like jargon and words are like exactly what they want to hear. And like they go on there and they read it and they like read the white papers and that like really helps to close sales. And I was like, whoa, like really? Like, are you serious? And he's like, yeah, I'm totally serious. And I was like, all of my like complaining about how this made no sense, like melted away in that moment. And I was just like, okay, like I was completely wrong. You know, like I was dead wrong about all of this. I still think there's some amount of massaging that you need to do in order to like divide the audiences into where they need to be because you don't want a developer landing on an enterprise marketing website being alienated and you don't want a person who responds well to enterprise marketing to land on a developer website and be alienated. And I always would bring up, and I still do bring up Stripe as a great example of a company who does that pretty well. They sell to developers, they sell to enterprises, and if you go to their website, they have sections on their site that are clearly tailored to both of those audiences and then funnel those audiences away into portions of the site where they can feed them content that they're going to appreciate. But it was like just such a mind-blown moment for me that I was like, this looks like complete nonsense and garbage, but like, this is actually very effective for like enterprise sales. It just like opened up this realization that enterprise sales is a completely different, like completely different world, utterly, than anything having to do with developer, like tools. And it was crazy to me that both of those could kind of coexist within the same spot.

And with such profitable complement.

Right. Yeah, exactly. It's honestly astonishing, right? That you could say like the top of our funnel is driven by one audience and our conversion is driven by absolutely different audience. And those two like are incompatible with each other. Like it's wild. It really is.

There's some incredible lessons. Lessons and all of that. I mean, there's your early management experience, there's navigating, you know, delicate political situations, there's the technical challenge, there's the pricing and packaging, there's like the understanding of the business model.

You could spend the whole, the whole podcast just on that alone easily, right?

Let's do a history of HashiCorp next time. What, um, one, you know, before we get to Clerk, you know, tell us, tell us the most important lesson from Vercel.

Hmm, that is a good one. From Vercel, there's so much that, that, that happened there. I mean, that was also a company that was growing like very, very fast. And from the time I joined to the time I left, like almost doubled staff, which was wild. Um, but that company was very purely developer focused. And at the time, like didn't really have any enterprise sales or any enterprise marketing when I joined. They were just fueled off the growth of the amount of developers who were interested in and using the project product. Later on, they ended up adding more sales and developing that more. But it was, it was interesting to see the process of that happening when it didn't exist. Whereas when I joined HashiCorp, they already had like a very, very robust like sales kind of like motion and team department built out.

Yeah. Because that's, that's like one of the easiest places to have like a real misstep execution-wise is like the—

Yeah, it is. And I mean, this is foreshadowing for what we're inevitably going to get into in Clerk later. So please ask about that, that same thing at Clerk, because I think it will be quite a surprising conclusion once we get there. But really, I think honestly, I feel like the biggest, ah, there are so many, but I feel like the biggest takeaway for me wasn't related to business development as much as it was related to career paths. I felt like within companies that I had worked at previously, there was this, like, there's this classic ladder where you like do IC work, you become a developer and then you stop. Like there's a cap to how far you can go. With that skill set. And in order to move past that cap, you have to stop writing code and go into like management and leadership. And I had a lot of strife around that, especially at the end of my time at HashiCorp. And around that time was when we started seeing more writing about people who are bucking that trend. I'm sure you've seen some of Will Larson's writings. He is prolific in his description of the staff engineer role. He's got a whole book about it. There started to exist this role of staff engineer and there were more writing about it. And it was like this sort of new role that was crashing through that ceiling of how far you can develop your career and your influence within a company as a developer in like a really interesting way. And I had sort of like flipped back and forth between management and, and IC during my time at HashiCorp in an interesting way. I started out doing IC work because I was the only one. Then I hired more people and then I was made the manager, but I also still was responsible for like being the lead IC and doing the architecture. And that stressed me out. And I felt like I was doing a bad job at both of those two jobs because I don't feel like you can juggle both of those. They require very different operating modes and ways of thinking and, and managing your time. So I felt like I was doing a bad job at it and I didn't like it and it was stressing me out and I was like, I'm done with this. I will promote someone else to being manager and I'll go back to being IC. And that was what happened. Eventually I managed to— we managed to get enough folks on the team that I felt like I could replace myself in my IC role and I ended up going back to management purely, which I never thought was going to happen. And it went fine because I was able to replace my job. I don't think you can have another job until you've backfilled your, your job that you had before, which I know we're not even talking about and I'm totally going on a tangent, but this is also like a very impactful like learning for me in my career path was like, I felt like as you developed your career, if you were ready to move up, which by the way, you don't have to do at any point, which is a whole separate point. Like if you're good with your job, there's no need to have another job or get a promotion. But if you feel like that's where you want to go with things because you're not learning enough or you're not growing enough for whatever reason, you have to replace yourself. You know, you can't just take another job and everything's going to be fine because because someone has to do the job that you were doing before, or else you wouldn't have that job and you'd be fired if nobody needed to do it, probably, right? So once I was actually able to replace myself, I actually really enjoyed management quite a lot. And that was what I ended up going to do at Vercel, was a pure management role. There were times where I touched the codebase and wrote code, but it was like, it was rare. It was about the amount that a manager, an engineering manager expected to touch code, which is like not most of the time. But within the company anyway, taking this full circle, What interested me was that it felt like there was a whole different level of the, like, staff engineer career ladder that extended all the way up to the top of the company and felt more powerful than non-engineers, crazy enough, because you would have people who were actually ICs. They spent most of their time writing code, most of their time in the codebase, but they sat in leadership roles. And having that type of person in a meeting was incredibly valuable because they're intimately familiar with the codebase, with the product, with everything else, and maybe they didn't know who was working on what or like what projects were in what state, but like the knowledge that they brought to the table at the leadership level was incredibly, incredibly valuable for an engineering-focused company building a dev tool. Maybe that would be the case for other companies too, but I can't guarantee that. And so it was really interesting for me to see within the company how, how many leaders were ICs, how many company leaders, like all the way up to the like C-suite. Where like had full IC workloads and I'd never seen that before at any company. All the people up there in like C-suite, like director plus, were not doing IC work at all. And it was really, really cool and interesting for me to see that trend kind of reversed in a way that I felt like actually made a lot of sense and was like really positive. Yeah.

That's an incredibly unique story. Um, is, I'm curious just to transition to Cleric, is Was part of that sort of evolution of the staff engineering role a reason that Clerk attracted to you, or was Clerk attractive to you for a bunch of other reasons?

It was, it was other reasons. Although I would say at Clerk, we do have a, we're very highly indexed on technical and IC-focused folks all the way up to the top. I would even say that Colin is borderline IC, and Colin's the CEO of Clerk.

So it continues, that trend is continuing at Clerk.

Yes. Um, and I think it's great and I think it suits companies that build tools for developers extremely well because if you're building a tool for a developer and you are a developer and you're using the tool and you're in the tool and you're in the code base, um, that's really nice. Maybe it also works well at non-developer tool companies. I don't really know cuz I haven't experienced that. I feel like it's worth a shot. Uh, I'm sure some company's trying it. Um, but I, I have seen a similar kind of like pattern and I really like that pattern a lot. And I'm mostly not doing IC work here. As well. But I know that I have, there have been periods where I've been like, we need you to do a project and I flip over and I just work on that project as an IC at times. And I know that if, if what I'm needed for is IC work, then that's what I'll do. And that's fine.

Yeah. That's awesome. For listeners who are not familiar, tell us what Clerk does.

Oh yeah.

Tell us why customers purchase it and use it.

Sure. Clerk is a It's a tool for developers to add the ability to log in, create accounts on a website. If anyone's heard of Auth0, that's a very popular kind of extremely similar tool in the market. Every kind of website and app more or less needs the ability for people to create accounts and log in and out of the website and manage their accounts and change their emails and reset their passwords and all those types of things. And so really, I mean, maybe some people want to debate me on this. I won't get into that. I would say you probably should not be building that yourself from scratch just because it's reinventing the wheel. Everybody needs roughly the same thing. And so Clerk's business model is we have a full team of engineers working full-time making a really, really good login user account experience that includes everything that you could possibly want. It's very well designed. It's very well put together. It's super secure. It's fast. And we sell that to thousands of people for a very trivial price because if you add together what those thousands of people are paying, it's enough for us to fund a full whole team. Whereas if you were trying to create a team to do that just within your own company, you're only effectively selling that to one person and you get a little bit less of a value trade-off like that.

I think many, so we are very kind of happy Clerk customers and many developers love Clerk.

Appreciate it.

And I think something that you guys did is you made this idea of components feel A, kind of like accessible and maybe to some extent popularized. Can you talk a little bit about that insight and yeah, for you all.

Yeah, I do think that's a big piece of what has put Clerk on the map in general, is this kind of components-as-a-service model that we've floated towards. And I would say, just to contrast it to how things were previously, normally what a company would do in the space is make an API available for you. So they would say, hey, sign up for a service, we've done the whole backend, we've got everything worked out, we'll even host your users in our database, and you can get that data out whenever you want or sync it to your own database. But like We give you these API endpoints for like signing in and signing out and resetting password. And on top of those API endpoints, you implement the way you want your login to work. Clerk does have API endpoints. You can find them on our website. You can go use them if you want, but the primary interface that we offer to our customers is a fully built out UI. A lot of our customers use React or React frameworks, and we have React components for that. We also have other frameworks supported across the board. We have quite a lot of them. But the way, for example, you'd use, use it with React is you would pull down a sign-in component. You would render that component on your page, and that's kind of the end of it. At that point, if somebody visits that page, they would see an already built-out login box. They would type their credentials into there. If it required 2FA, it would deal with that for you. If it requires you to go to Google and do OAuth and come back, it handles that for you. And it brings you back to a page that's signed in. And beyond that, we have a component that's like signed in and signed out that you can like wrap around and conditionally render other components in that way too, if you want. But it's very much like all the way down to the level of like what you're saying, which creates a lot more work for us and a lot more surface area to maintain across a lot of different SDKs and frameworks. But it just makes the user experience that much easier. A big part of what's difficult about building login is the UI. And I've learned that very intimately as an employee of this company, because The code that we put into making UI work is crazy. I think a great example of that is like, let's say you have email password. It's not so hard, right? You make a box, you put two input fields, you put a submit button, you're good to go. It's like, ah, you don't need to buy Clerk for that, right? However, let's say then down the line, you're like, hey, we want to, you know, we want to add the ability to log in with GitHub and Google because we found a lot of our customers are using that. It would increase our conversion rate. So like, let's add those in. Now your engineers are back in there adding different methods. Adding OAuth callbacks. Okay. Hey, passkeys just came out. Passkeys are pretty cool and trendy. We want users to be able to log in with passkeys. Now you're back to the login box. You're back to the backend, figuring out how to add that. Hey, we've had a security problem. We want to add, uh, multifactor auth. Okay. So you gotta add in multifactor auth. Hey, we have this thing where we want to take their first and last name because we want to be able to address emails to them and personalize them because it's shown that that has a better conversion rate. Okay, so we'll collect that in the login form. But now what happens if they sign in with Google? Google doesn't give us first and last name, perhaps. So then we need another follow-up after they come back from Google to collect the first and last name, or else we'll have a bug in the emails to anyone who did OAuth. And it just like spiders out. I mean, I've, I've like scratched the surface of the tip of the iceberg in the number of scenarios that just end up adding up and becoming more and more complex. And all of those are not just API problems. Those are UI problems that you need to design. Relatively complex UI to handle. And when you go with a company like Clerk that provides the UI for you, those are just done. So if you wanted to add passkeys, you go to the dashboard, you check the box that says enable passkeys. That's the end of your work. We've already written the logic for that into the UI components, and it just automatically reflects onto your page, which is really cool. And it's just one of those things where it saves you time that you would spend working on effectively a side project that's not really contributing directly to your product success instead of spending that time working on your product directly. Exactly.

Yeah. And it's, it's one of those kind of classic buy versus build offers in the market.

Exactly.

And as you described, as such, there's just a long tail of paper cuts that inevitably come when you decide to build and house it.

It does. You know, and this is why it amuses me every time I observe the roll your own auth debate, because I'm like, one day you will realize what you've gotten yourself into by deciding to build your own auth.

And it's a relatively predictable pattern. If you decide to go down the path. Totally.

Absolutely. There's no question it will end up becoming very complicated if you end up becoming a big and successful company. And I mean, that's part of the reason why we try to— maybe back to what you were gunning for here anyway, naturally— we try to price in a way that makes sense for people where we're not charging them when they're just getting started at all for a very long time. When we start charging them, it's a very trivial amount of money. I think $25 a month is our lowest tier. The only time you end up paying Clerk a lot of money is if you have a really, really big app that's really complicated. And hopefully you feel like that's justified because we've saved you a lot of time and provided you a lot of value that you would otherwise end up paying, you know, I mean, frankly, hundreds of thousands of dollars to dedicated developers to make sure that that system is well maintained.

That's a great segue into pricing and packaging.

I got you.

Thank you.

You're welcome.

Well, tell us, so yeah, you've described it lightly. Just basically, how does Clerk pricing package today? Like, is it a seat model? Kind of walk us through the basics.

It's very hard. It's very harsh. What our, what our goal is, is like underneath all the specific details of the pricing, our ultimate goal is that is to almost price in the way that Stripe does, right? They have a very, I don't want to say easy, but like the way that they've structured it is easy for you to make sense of. If you make more money from billing people using Stripe, you pay Stripe more money. If you make less money, you pay Stripe less money. Our philosophy is we want that to be the same way. If you are very successful and you've made a lot of money and saved a lot of time and gained a lot of value because of Clerk, we would like to ask you for more money because we feel like that's fair. If you're just getting started, we would not like to ask you for anything because we want you to get off the ground and make sure everything's going well and that you are making money before you start paying clerk a cut, and we want our cut to be quite small because we're perfectly happy taking a very small cut across a large swath of the industry. That's fine. That's plenty to float our company finances. How you actually implement that is a whole different story, right? With Stripe, they just say, hey, we take whatever, 0.2% of all your payments, and that's done, right? Everyone's like, okay, well, I can't argue with that. It's fair. For Auth, we don't really have the privilege of being able to do that. We're not going to like take a percentage of your revenue as a company. That's not really how pricing works, although maybe it should be how pricing works. I don't know. So we have to come up with these sort of arbitrary metrics that we charge for that we feel to the best of our knowledge correlate with the size and complexity of the scale that you're operating at. The free tier is—

go ahead.

Sorry.

Is that to say that we're trying to find a metric that correlates to the value you are getting from Clerk service?

That's the goal. And sometimes in some circumstances we're off on that. Where people are paying Clerk more than they feel is fair that they should be paying. And that's our mistake. And we don't see that as like, oh nice, like, you know, we squeezed some extra money out of like a small struggling startup. Absolutely not. Any feedback that we get along those lines is usually a way of utilizing Clerk that we didn't expect. And they end up getting overcharged for resources in that way. And we need to go back to the drawing table and figure out, I mean, obviously, first of all, we'll cut them a discount if they reach out and they're like, hey, this is an unfair amount of like cost that you're putting on us. We're very friendly to that and we'll figure out how to make something work for you. That's not our goal. But we also need to go back to the drawing table and figure out, hey, how do we adjust our primitives to make sure that if somebody else lands up in the same spot, they don't end up feeling like we're charging them an unreasonable amount for, for where they're at as a company.

Applied in everything you just said is a very kind of simple observation, which is we're pricing for adoption, we're pricing for early-stage companies to be able to access this product, whether they are You know, this is a side hustle. It's like not even a business yet. We want them to go with us too.

That's absolutely the goal. And Clerk's like strategy as a business is something that I had never encountered at any other company that I've been at and was astonishing to me once I came to terms with it here as well, which is something we touched on earlier, which is effectively we don't do any enterprise sales. None. We have zero salespeople. We have no enterprise marketing. We have had enterprise companies come across the table and ask if they could do business with us and said no. And when I first started working here, I was like, What is going on in this place? This is, this is insane. We're just leaving massive amounts of money on the table. What is happening? Like, why are we not like hiring salespeople? Like, why are we letting these deals slide when we could be prioritizing this one feature and that would, you know, close us a bunch of big enterprise deals? And what I came to realize is that this strategy that Clerk is employing, I now like so much that I don't know if I would ever go back again. And the theory is like, if you can hold off on doing enterprise sales as long as humanly possible before somebody, investors, you know, the market forces you to do that, you are able to focus on making great product more effectively. And the reason is, if you as a small company say, hey, look, we're going to try to be successful, we're going to try to close a big customer, a big enterprise customer that pays us a lot of money, which is great for you as a company to make a lot of money, of course, you end up being beholden to that customer., right? If that customer comes to you and says, hey, I want this specific feature that we need for our implementation, you say yes because they're your biggest customer, they're paying you the most money. What, what else are you going to do? However, that very feature could well be for a dramatic minority of your actual user base, and it could well pull your product in a direction that doesn't actually make the product better for anyone other than that one customer. It might make the product worse for all of your other customers. For that one customer, they're happy with it. And then you start multiplying that effect, right?

Okay.

Do that once and whatever. It's not that big of a deal. It's one extra feature. It's not going to ruin your product quality. Now you have 10, 20 enterprise customers. They're all asking for things. You're building things for those enterprise customers. All of your free customers, all of your startups, you don't really have the capacity to build features for them. They're not paying you any money. And meanwhile, you've got 10 customers over here paying you huge amounts of money and they're very important to you. And you talk about them in your case studies and their logos are on your homepage and they're floating your business to success. So like, of course, like this is what you have to do. And I think this adds up and it adds up and it adds up. And what happens is eventually you have something like a Salesforce, you know, which is like Salesforce is very successful. Don't get me wrong. They make a lot of money, but I think you'd be very hard pressed to find anyone who comes to you and says like Salesforce, yeah, it's a great product. Like I love it. It's like intuitive to use. Uh, it's clean. It's focused. It's not, it's the amalgamation of the features that every enterprise customer has asked them of over years and years and years crammed into the same spot. And that's like not what Clerk wants. Like, it's just not. Clerk wants to build a really great product that is focused, is opinionated, it's clean, it's easy to use, it's straightforward, it's beautiful, and it works for the largest number of people across the widest swath of the market possible.. And the way that Clerk plans to make money is if you adopt as a startup and then you grow into being a large company. That's where we like see our success stories coming from, rather than you already are a large company and Clerk goes to you and tries to convince you to use Clerk, which is a very unconventional strategy as far as I know, uh, within tech companies. But I think it's really cool and really interesting. And I love the fact that it allows us to focus more on product quality and more on like the craft behind what we build. I love it so much. I'll stop talking now.

I mean, it does resemble Stripe, right?

Yes, certainly. Certainly.

You know, it's, it's, it's a, it's, and just to play some of this back, right? Like the business is basically committing to, we're going to build for a very specific segment of the market for as long as possible.

Yes.

And we acknowledge, we acknowledge that in order to be a big company, we will eventually close enterprise deals. But first and foremost, those initial enterprise deals are going to come from the startups that we grow with.

And we've seen that happen already. Crazy enough, we have one customer who's so big.

Yeah.

That I think they're like more than half of our like, uh, total managed users, which is crazy. And this was not a customer that we, um, this is not a customer that we like sold or like sent salespeople over to. They were a startup. They used Clerk. They grow into being a huge company, which is just really cool and gratifying to like see that happen. Happen. And hopefully it happens more.

And hopefully it happens more. And then eventually there will come a day when there's probably a question asked, which is, is the product ready to serve an enterprise customer even if we have not grown with them from the beginning?

Correct. Yes. And that's something that we need to keep pace with. But generally, like, yeah, it's an interesting challenge, right? Because we generally don't prioritize enterprise features over features that people need in order to even use it at all.

Well, and I think one, one lesson that I've often heard people, like I've interviewed so many people who feel like one of the biggest mistakes that they've made is jumping to enterprise too soon. And there's an enormous amount of discipline that is required to not make that jump prematurely.

And I mean, by the way, turning down a big deal on your doorstep, right?

And you have tons of investor pressure, right? Like, yes, presumably, I mean, you may not, but like many companies have tons of—

everybody does, including us.

And so there's, there's just all kinds of incentive to go make that move, even when you feel like you're not quite ready for it. And so many people mistake that moment, and then they have to redo that moment several times over in the pursuit of market. And it's not just that it distracts from the craft, it's also that, like, you resource the company differently. Like, the whole business changes culturally.

It's true.

It's really kind of— we could have a full conversation on this.

Absolutely. I'm so interested in this idea. I hope that there are more companies that pursue this path. There are a few investors that I've spoken with who have picked up on this and are like actually quite warm to this idea. And I think that's super, super interesting to me. As you said earlier, a lot of the pressure to move away from this sort of philosophy comes from investors, reasonably so. They want your company to make money. They want you to be big. They've put a lot of money into it. I get it. But seeing some investors start that I have conversation with start to shift their focus towards being like, hey, I think that we actually end up seeing more long-term success if we invest in this company building out about, you know, a truly great, like, generational product, even if it means that it takes a little bit longer for them to start seeing revenue, is really cool and interesting for me to start seeing some of that.

Can you talk for— I'm sad that we have only an hour today, so hopefully we do this another time.

Appreciate it, man.

We were joking at the top of the hour because I'm in my— my dad's a therapist and I'm in his office and we were joking about laying down on the couch. Tell us, you know, a question I'm always really fascinated by is sort of just the underlying infrastructure that supports pricing, packaging, monetization. Can you just paint a picture of how pricing and packaging works architecturally at Clear?

Yeah, it's, it's quite complicated for us, unfortunately, because we have so many different things that we meter on. So I'm, yeah, I guess I didn't actually get into how we were priced when we were talking about that, but I'll, I'll, I'll paint a broad picture of what our pricing looks like first, and then we can dig into any specific aspects. We have a huge free tier. It's super generous, absolutely essential to our business for reasons that are probably obvious at this point. We really want people to be able to use Clerk without paying us anything for as long as they need to really get their business on the rails. So the free tier lets you go up to 10,000 monthly active users. That doesn't sound that crazy, but I've gone through— we have access to quite a lot of data about people's users and how many of them are active, given that that's what we do as a company. And I think the total number of users versus the number of active users is a split that a lot of companies don't really thoroughly consider. It's usually like maybe a tenth, less than that, that are actually active of the total people have signed up. On top of that, we have this really interesting program that we rolled out in the last, I'd say, year or two called First Day Free. And what this means is if somebody signs up for your app and then they never come back again, which happens a lot, to be clear, a lot. And we also have the stats on that. It's insane how high those numbers are. We don't ever charge you for that. Them. Technically, they would be a monthly active user for that month because they logged in during the month. If somebody logs in during the month, they're active. But if they just created an account, they logged in, and then they didn't come back the next day and we didn't see them again, we don't charge for that. Free first day, free to post first day free, we saw reductions of 50%, 60%, 70% for the bills for some of our customers, which is crazy. But it makes it a lot more attractive when you look at those numbers and say, oh, I'll get more than 10,000 monthly actives and like, then I'm going to have to pay Clerkly Probably you won't, just saying, probably won't. It really takes a long time with first day free plus actives to get over that level. And it's extremely, extremely rare that that's the metric that caps somebody out of the free tier. It's usually another feature that they want to upgrade to well before they hit that limit. So we could increase that limit if needed, but we haven't seen any need to do so. And we have competitors that have higher limits and that's fine, but ultimately it's like more of a marketing tactic than actually an effective like, right, way to give people more. So monthly active users is sort of like our base. That's almost like the Stripe percentage fee. Beyond the free monthly active user limit, we charge you something like a cent or like 2 cents per, per month per active. As you get more and more, we reduce that cost more to make it affordable for you. So the number of active users on your app is the like base driver of what you're paying Clerk, which we feel like is a pretty good approximation of what's fair to charge because it really represents the size and scale of your app. Yeah, it's my internet messed up.

No, you're good. Okay, it's probably—

it's all good. Uh, okay, then beyond that we have like other like specific features that we put behind paid tiers because we feel like those are features that typically are used by larger organizations. Things like SAML connections, things like— I don't know, let me see.

Well, impersonation would be one, right?

Impersonation is a good one. Uh, we want to start adding a number of free impersonations to let people people test that out and like see if it works for them because that's a really cool, really useful feature that we get tons of value out and we feel like our customers get tons of value out of, but it's kind of locked up behind there and it's really only useful in production. All of our paid features, by the way, are also free when you're in development mode because it allows you to sort of like try them out without having to like go get a trial or anything from us and see like what works for you. But impersonation is one of those ones where it's like how useful is that in development mode versus prod? Usually it's like somebody puts in a support ticket saying something's going wrong, then you can impersonate their account and go look at their settings and figure out, or like reproduce it as them, which is really useful. Satellite domains, another one. Device tracking revocation. We have, uh, organizations and roles and permissions where we have a certain cap of those and we're like, once you're past a certain number of roles, it's pretty likely that you're like a big organization. So those are the more dicey things. That we can hopefully make an adjustment to like fix or improve. But that's how we charge. And then we also have to charge for SMS, which is an interesting thing because we use it, we just pass through SMSs to a provider. We don't make money off of those. We just pass through charge. But a lot of people use SMS, they use it for OTPs or they use it for other things. And we have to figure out a way to pass through pricing for that as well. And also, if you are not familiar with SMS pricing, which I hope that nobody listening is because it's a mess. It changes in real time. Fun fact, the amount that it costs to send a text message to anybody anywhere in the world could be different from one second to the next second. And it's different per SMS provider. And so we have different SMS providers as backups because if one fails, then we can fall back to the other one. And so that's a whole crazy business. We sort of have tried to like pin like a, like 5-cent range that's like stable that they fluctuate within and then just charge you that to make it simpler to understand. What you're paying. Sometimes that makes us money, sometimes it loses us money. The goal is not to do either, but just to make it not change in real time because that's very surprising. But I've seen cases where months and months it's gone up or down by 30 or 40 cents to send an SMS message. I'm like, this is crazy. So we have like the SMS pass-through costs. We have the like pass-through costs of like metered things like monthly active users, monthly active organizations. And then we also have, if you're paying like a base price for like access to a set feature. So pricing is really complicated. And the way we bill is at the beginning of the month, we charge you the base fee. If you're on a $25 a month plan, you'd get a bill for $25 at the beginning of the month. And then it also tacks on any like metered features from the previous month onto that one. So if you send 100 text messages and we charge you whatever, like $2 for that, then you would pay $27. So our pricing is actually completely insane. And I know that we've we've kind of run out of time here, but I'm happy to answer more questions if you have them about our pricing.

Yeah, we'll, we'll pause for a second. How are you on time? Do you— are you hard stop right now?

Pretty close to it. I don't think I could go more than another like 10 minutes.

Okay, why don't we try to wrap by 12:10?

Okay, that sounds good. Let me just— one sec.

Good. Okay, so it sounds like basically we have a hybrid billing model. There is some con— some combination of usage-based billing, some combination of feature-based billing, right? Tiers. Can you talk a little bit about how this works from a systems perspective? I mean, like you have multiple stacks, I would presume, that are governing how this actually ends up working, you know, from the billing system into the product stack. Can you just paint a picture of like feature flags, entitlements, metering? Have you built that? Have you outsourced that? Can you just paint a picture of like systems architecture that governs?

It's mostly in Stripe. Stripe. So Stripe carries all the base plans and also kind of carries all the flags. So the plan includes some like metadata about like what features are included in that. That we store in a table associated with the user in our own database. And when you subscribe for the plan, then those features unlock. So that's relatively straightforward and it's not so bad to handle with Stripe. The metering is, is largely kind of like custom logic that we put together in our backend. So like we need to consume information from like Twilio and from Prelude, which are our SMS providers and gather that up and then pass it to Stripe at the end of the month. Likewise, with monthly active users or organizations that comes from Clerk itself. So we need to gather that from our own database and then pass that through. So I mean, it's just kind of just a bunch of code that we've written to do that type of stuff.

Makes sense. We should do this again. We both have to go. Question I always like to close with, and you described a lot of this at the beginning, but if you had to narrow down on on a most formative moment in your career, what do you think it would be?

That's a big question. I don't know. There's a lot of them. I don't want to like readdress another one that I've already touched on. There've been a few. I don't know. Let me, um, so, okay. Let me pull out a completely random one. There's a time where I was at the agency I started on and I was working on build tooling for like websites and applications. And I did this by hacking Webpack in really, really crazy ways. And anyone who's interacted with Webpack probably knows that. It's insane. And it was insane. And at one point I was trying to figure out how to consume a tree of like assets and resources that were needed in order to build an application and split them out into several different, like smaller packages. And then distribute them across multiple cores to build and then have them combined back together at the end in order to spit out the resulting application. And I spent like, like months and months and months doing this and like wrangling them through build systems. And at the end of the road, I like found out that basically like there were a bunch of things that you might need to do for a website that would require you being able to pull contextual knowledge from those different things. Like for example, For example, if you were building a blog, this is like the simplest example, you might have an index page that lists all the blog posts. So if I cordoned off, you know, 20 blog posts into this core and 20 into this core and 20 into this core to compile and pull the metadata, I would be out of luck because what core do I put the index page in? It can't access the information across any of the other ones and doesn't know when they finish compiling. And it was like this crazy, like, problem for me that I spent, like, months and months and I was, like, so close on it. And I like never got there. And the end of the project was just like, I give up, you know? Uh, and it just like, it felt really terrible. That was like the closest I've ever felt to burning out in my career. I've always been like really excited by stuff that I was working on. I feel like I'm an easy person to get excited about working on stuff. There's like a million things that I'd love to work on, even if it seems boring. I'm like, there's some way you can find cool, interesting opportunities in here. But man, that, that one thing like really got me.

So, uh, that's an interesting one.

Regardless, I'm fine. Sometimes you do a project that like you put your heart and soul into and you really think that you're doing something interesting and special and it's just a complete failure and you mess it up and you just weren't good enough for it. And like, that's fine. I think that happens to everyone at certain points. And I just wanted to share that as a way to make anyone who's listening who feels like they've like completely blundered a project before. Felt bad about themselves because of it, just be like, you know, it's something that you can learn from and move on. And there was a lot that I got out of my work on that project that served me well for the rest of my career. It was some of the most challenging code I've written. It was some of the most challenging architecture I've written. I became a master of promises and asynchronous flows and JavaScript because of it. So I don't know. I don't know if that's useful, but like, I just remember that moment, you know, there was just nothing. Anything in there that was gonna be worth using and just feeling so awful about it. Now looking back on it, I'm like, that's just something that's gonna happen and it's okay. That's all.

Fantastic story. You know, one of the, one of the things I'm hearing in, in the answers to that question, the more people I interview is kind of a common theme. Either it's a moment when I took a big risk or it's a moment when I failed. Yeah. It's like, it's often one of those two. Yeah.

I mean, and I think those two go hand in hand a lot of times. Sometimes it does play out and that's great, but Yeah, 100% going for it is always the way. And at the very beginning of the interview, I mentioned this briefly. That's like part of my philosophy is just always go for it. If someone asks me to do something I don't know how to do, I'm going to say yes to it every single time. And that's never done anything less than serve me super well. So always go for it.

Maybe that's the name of this episode is just go for it. And if we do another one, we've got to get into what you've learned about pricing bagels. Because we did not.

I have more. I have more there for sure. That's an interesting story, especially in Serbia. There's a whole, whole thing.

Jeff, it is so much fun to talk to you. I've learned so much. I think everybody else will learn a lot from this conversation. Thank you again.

Yeah, thanks for having me on. This is great.