Ep. #124, Complete User Management with James Perkins of Clerk

Brian Douglas: Welcome to another installment of Jamstack Radio. On the line we've got James Perkins. Hey, James. How are you doing?

James Perkins: I'm doing good. How are you? Long time fan of the show.

Brian: Yeah, yeah. Pleasure. You worked in Jamstack companies in the past and so happy to have you. Also, you're prolific in content creation, you have a TikTok, you have a YouTube, podcast. Actually, you mentioned you have a podcast. What podcast do you do?

James: Yeah, so I do a podcast called DevelopersHangout, and instead of talking about tech all the time, we talk about the other stuff that we do like projects and hobbies and fun things like that to keep it light. It's nice to digress from all that tech that we normally talk about every day.

Brian: Excellent. Yeah, and so I wanted to actually ask, so you talk about your podcast which is basically the last 10 minutes of this podcast, it sounds like, you're entire podcast. Which is our Jam Picks. But I did want to ask what's your... Can you just give us an intro on James, who are you, how did you get there?

James: Yeah. So my name is James Perkins. I've been in the industry for over 13 years now, working from big, big, big companies, all the way down to small startups, pre seed, seed and Series As. Yeah, I make content on YouTube, educational content, things around the Jamstack mostly, mostly NextJS stuff, and then obviously I have a podcast and I do a lot of stuff on Twitter. Yeah, that's me in a nutshell.

Brian: Excellent. Yeah, you've been around. So what's the biggest company you worked for?

James: I worked for IGT which is the largest provider of the lottery and also slot machines at Vegas. I worked there for a couple years. That's probably the biggest one.

Brian: Oh, excellent. You probably shared the secret sauce of the algorithm.

James: Yeah, it's actually kind of a weird algorithm and it takes months of testing to just get the right amount of wins per machine, then they have to do a bunch of closed source code that goes in and it's just Java, if anyone's interested. Then they put that in the machine and then that's how they program it on a little, tiny board. It's wild. Craziest thing I ever saw.

Brian: Yeah, sounds like a cool weekend project. I don't know Java though, so I guess I'd have to make it in JavaScript, the other Java.

James: Yeah, the other Java.

Brian: Excellent. Yeah, and you're working at Clerk now, so can you give us a quick rundown of what's Clerk?

James: Yeah, yeah. So I work at Clerk and basically you can think of Clerk as complete user management for the modern web, so we're talking NextJS, React, Expo, those kinds of frameworks. And essentially what it allows you to do is to have high converting, sign in and sign up, and also things like user profile, organization management, all those kinds of things you need to build the next SaaS or your next side project where you need authentication.

Brian: Yeah. This is the part of the conversation where I ask the naive questions that everyone's thinking of. So when you think of this customer management, this authentication, so how does Clerk compare to things like Auth0 or like a Stitch?

James: Yeah, so if you look at Stitch, I guess Stitch is always a good one. They're kind of in the same realm as us. Stitch uses APIs, right? They give you a bunch of APIs and you build your own UI out from those APIs. What we do is we do it a little differently, so we give you prebuilt components that you can mount to your NextJS app, or you can basically embed them with the standard components you'd see in React.

Then we allow you to customize them however you want, localization, appearance, all those things, and you can keep that all within your application. Unlike Auth0 where what usually happens is you get redirected outside of the flow, so Auth0 will put you on their own UI and then you click through and everyone knows what Auth0 kind of looks like.

We give you that and then we give you a bunch of hooks, helpers and APIs to manage that user state, so if you need auth tokens to talk to GitHub, you can do that with a simple API call. If you need to protect your pages, you can use things that are already in frameworks. So NextJS, you can use middleware to protect pages and we'll allow you to handle that all yourself. Essentially, we're basically the modern web's version of Auth0, but we do it much better. That's my big pitch.

Brian: Excellent. All right. Well, I'm intrigued because back when I worked at... I talked to Colin, the founder of Clerk as well, about this story. When I was at Netlify we had built the Netlify identity widget, which was the way to authenticate what's now the transferred project which is now Netlify CMS.

It was specifically built for that one interaction, so that also was Go True which is the open source library that built it, it also does the authentication, it was also built during that experience. All those things still exist, but it's not Netlify's focus. It's not their main bread and butter of their product. It sounds like Clerk fits in that gap, which was that side project we had, which was Netlify Identity, Clerk can also handle that for folks.

James: Exactly. Yeah, that's the idea. Here we're just like authentication isn't hard, per se.

Brian: Famous last words.

James: Right. Yeah, I'm going to get roasted for that. Colin will be hitting me up on Slack in a minute, and be like, "Hey, I can't believe you said that in the podcast." But no.

The idea here is that it's not overly hard but there's a lot of complexities that you have to think about right, like how do I use JWTs? How do I refresh tokens? How do I handle if someone happens to accidentally get access to someone's account? How do I handle O-Auth for all these different providers? All those kinds of things start to add complexity to projects. Our idea here is that, hey, if you want sign up on this page, the component is sign up. That's it.

That's the end of your signup experience. Then you just go on a dashboard and say, "GitHub, Google, Twitter, Twitch. Those are the ones I want. I want all four, I want email and I also want password." Hit save and even if you're embedding that component, we will handle that for you and we will show the UI the way it should be shown to the user.

Brian: Yeah. This is something, I saw a tweet actually today from @mscccc, which Mike Coutermarsh. Some people know Mike who works at PlanetScale and he was joking that if you want to get a promotion packet done for yourself, go build new auth inside the project you're working on. I come from a world where I studied on Ruby on Rails back in the day, so we all used the Devise Ruby Gym which sounds like we have similar backgrounds, really similar backgrounds.

But, yeah, you use Devise Ruby Gym or you use Auth0 or you use the same thing, or you build your own or you manage your own JWT, pass it around, generate that stuff. Even at OpenSauced, we're using Supabase for our auth today. But the challenge is there are some edge cases that we're hitting, we have multiple projects that we built with the same authentication library, same database, same authentication, separate NextJS apps.

This one's over here, that one's over here, so to handle the redirect we actually had to press Supabase to ship something for us. Well, not for us, but we were in the discussion and the GitHub issues and being like, "Hey, we need to redirect from a random Vercel app or a random Netlify app, or random this URL, but use the same authentication." And that wasn't something that was in the original roadmap for their authentication, but it sounds like Clerk is a little more malleable and flexible in that situation.

James: Yeah, so we have basically two developer paths, maybe three, but really it's two. So you have developers that just want auth, so just put this component on the page and you're done. The end of the day, you've now got signup, you've got sign in, you've got all these different flows. Then there's other people that are like, "Hey, I need some weird edge case that maybe not many people are using. How can I implement this with Clerk?"

And we give you basically low level APIs or helpers to do your own flows. If you need a specific flow with specific redirects and they need to be dynamic, and all those kinds of things, you can do that with Clerk today and you just write it yourself. We give you all the hooks, we tell you how the hooks work, how the flow should work, and you can just basically use that to make your own flows, your own redirects, your own handling of things like that.

We've got new features coming out for things like satellite applications, where maybe you share a database but you have like three or four different apps that are satellite apps that aren't the main one. We're shipping that, which will be probably out before this podcast goes live. But things like that, where it's like, "yeah, we understand that sometimes you've got to share a database of users, but each one of them has their own nuances and new apps or whatever."

And you can do that with Clerk. Basically if you think about how, let's say, Planet Scale, their main focus is making good DX for databases. That's what Clerk does. We make good DX for authentication for developers.

Brian: Excellent. So you mentioned Stitch, but it sounds like you're in a very interesting position, where there's a new evolution of the web and people... I don't think everyone is centralized on NextJS, but I think a lot of people are using NextJS and React, so now you've solved that problem for React devs, for JavaScript devs. I guess what's next for Clerk?

James: Solving it for more frameworks, I think is the answer. I think the answer really is how can we also solve this for B2B SaaS because B2B SaaS is hard. If anyone has built business to business-

Brian: Yeah, like single sign on.

James: Yeah, like SSO, SAML, all that stuff. So we have that shipping soon, we'll have SAML. But there's also the other part of it, if you want to build your own business to business SaaS there's things like, "I need organizations. How do I decide who is an admin? Who is a member? Who is a super admin?" All those kinds of things we're solving right now and making them better every day.

But I think the real answer is we're going to go and build something else, RSC components for React Server Components. That's already planned, to have full RSC style components. We already have them in NextJS so if you use Appbrella you can use server components today, but we want to provide those for vanilla React. Then we've got things like Android and iOS support coming up soon too. We're going to breach more into the mobile web outside of JavaScript frameworks.

Brian: Okay, perfect. Yeah. This is exciting times too, as well. Also Clerk has recently joined the Jamstack fund as well, so in good company with a bunch of other projects that are solving specific problems that eventually expand to bigger solutions. I do like the idea of the role based access control, which is something, being able to have admins and super admins which you were going through, that conversation or example.

That's currently a problem that we're actually trying to solve right now for OpenSauced, where we do have the ability to share data amongst other folks but we don't have the team feature shipped yet. But now the question is how do we maintain this person having access to that? We're building a table, so we're doing all this from scratch inside of our Supabase tables today.

But it sounds like Clerk gives you that, not for free, maybe it's a paid experience. So how does this breakdown? I'm a developer, I'm building an app, do I have a free tier for Clerk? Or am I quickly into my $20 a month situation?

James: Yeah, so the way that Clerk works is that we give you a free tier. Right now as of the recording, so I can be open, we have a limit of 5,000 monthly active users. That means that 5,000 users have to at least log into your app in the month of, let's say we're in April, the month of April. If 5,000 users log in during the month of April and are active in your application, that is the maximum amount of free that you can have.

With that, you get the ability to build organizations, that is in the free tier. So if you want organizations and you want to build B2B, we offer that but you have a limited amount of orgs that you can build. Then things like specific features that aren't available, things like allow list, which is a way to basically have an invite only application.

Those things aren't available, and things like phone which is costly currently is not available on the free tier. But we are planning on making the free tier even more free, in that the monthly active users is going to grow so that you get more of those if you want to be on the free tier.

Brian: Excellent. Just want to let everyone know, if you have 5,000 monthly active users you might be able to raise VC money.

James: Right, exactly. We set it at 5,000, and then we felt that was fairly generous but we think we're going to bump it up a bit more for free users. Maybe it's a free app, or maybe it's something in the open source space, or something like that where they're not really bringing in any revenue but they want to be able to offer this service. We want you to be able to do that, so we're going to up those limits.

Then, yeah, after that you start to go into the hobby plan which is a dollar amount a month and that unlocks other features like removing Clerk's branding, it also gives you the ability to use phone if you want to, the allow list gets unlocked. So basically we gate features depending on what kind of tier that you're on, and we make it really clear and upfront, even in development.

So in our development environment, everything is unlocked, so if you want to test out, "Well, maybe I want phone, maybe I don't want phone. Maybe I want this, maybe I want that."It's all unlocked in dev, but we tell you straight up, like, "Hey, by the way, this is a paid feature. So if you decide that you're going to dev with this, when you go to production you're going to have to pay." We make it as clear as possible that, like, "Hey, everything is unlocked in dev mode, but once you go to production you will have to pay.

Brian: Yeah, that's clever. Yeah, my engineer brain is like, "How do you gate that between dev mode and production mode?" I'm sure it's super elegant and clever, or probably extremely simple. So I was going to go into that detail, but I did want to actually talk through your role at Clerk and just the developer experience, developer relations advocate. What sort of things are you doing to engage developers at Clerk?

James: Yeah. I'm doing something a little different than probably your standard what people would consider a DevX or Dev advocacy. My time right now is spent less creating content and more focused on how can I help users today have a better first touch experience with Clerk, versus me having to help them get past that first touch.

So right now I spend a lot of time, I'm actually rewriting Clerk's documentation from scratch. It's completely open sourced now, so basically if you're a dev and you want to come and help Clerk you can come and push PRs to our docs, find an error, find maybe a cool snippet that you've written. Those kinds of things we can now do.

On top of that I'm actually working on through support flows right now, where I'm helping our support team which is a one... we have one guy supporting this million managed users at Clerk. It's just one guy on his own, so I'm helping with that by creating Discord bots and using some fancy AI behind the scenes to deliver up docs which is coming soon. Things like that. Then improving our flows in general just to make that easier.

Brian: Okay. That Discord bot, is that open source as well?

James: Yeah, it will be open source as well. We haven't finished it yet, we're still writing some stuff for it and tweaking some stuff. But, yeah, the idea here is that, like, hey, if you want a Discord bot that someone asks a question, the first response from the Discord bot is like, "Hey, we've got your request. Here's all the things you can do to help us.

Based on your question, here's maybe a link to a doc and then someone from our support team will be along shortly." That's the idea. It could unstick the developer without the support team even needing to be there, or it could at least give us all the details we need to go and talk to engineering or for our support guy to go and debug those kinds of things.

Brian: Okay, excellent. Yeah, that sounds like fun. Also, knowing you from your content, it's interesting to hear the other stuff you're doing like the support workflows and documentation which is a big need for developer experience as well. I'm curious of your thought, just on the podcast, the Software Snackbites and talking about DevRel.

We don't need to go deep into this conversation, but there definitely is a something happening where a lot of folks are getting laid off in the DevRel space and I wanted to touch on that subject because I know you've gotten laid off previously. I'm curious, do you think there's a change happening right now in DevRel?

James: I don't know whether or not it's a change. I think the attitude towards DevRel has kind of changed, maybe.

A big thing for me was I saw a lot of companies hiring influencers as DevRel and thinking that was the solution, right? Someone has a 100k followers on Twitter, they must know what they're doing. Then they come to find out that they have no idea how DevRel works and how to help those feedback loops and all those kinds of things. They just know how to market.

So I have seen this big change in companies now hiring people that actually may not have huge followings, or may not have big YouTube channels or may not have all these things, but they have good experience in delivering either high quality content, written, video or whatever. But also are really good at producing feedback loops that allow developers to actually feel heard, and also feel like the company cares about them because people believe that.

Even at Clerk, people have asked me like, "Oh, you must have like 100 people." I'm like, "No, when I started here it was like 10 people and now it's less than 30 people." We don't have a huge team, we're not Auth0, we're not Amazon or anything like that.

It's a very small team but we're highly productive because these feedback loops allow you to complain to me, and then me to advocate for you, like, "This is a good reason, we should do this. How can we get this guy unstuck?" Those kinds of things. So I think there is a change, but I think it's more about companies understanding what DevRel actually is versus what they thought it was.

Brian: Yeah. That's actually extremely valuable too, as well. Because I did a ton of conversation with early stage founders about these early DevRel hires, and my consistent feedback was, "Probably don't hire a DevRel person." First 10 people at the gate, unless you really, really know what you need and you know what you want to get out of them, don't hire them.

Because it can't be on the DevRel person to figure out once they hit the ground running, though really good DevRel folks will be able to figure it out but I think at that point you're probably overpaying, to be quite honest. But I think what I heard from you is the feedback loop is actually the most valuable part of that experience, it's getting someone that can get information from developers and then having a response to that.

So in my world, I did work for a very large company which was GitHub. Honestly, very large is kind of a stretch.

James: Yeah, that's a stretch.

Brian: Yeah, we were less than 2,000 people for my entire time that I was there. But presented as a much larger company. But I also did that feedback look thing pretty consistently where I didn't want to be the person always being in front of the camera or writing the blog posts, but I wanted to unlock getting those individuals that do that stuff to use their network to get feedback for GitHub without burning myself out. I think that took a lot.

What I saw 10 years ago in DevRel was a lot of developer advocates and really good engineers moving into DevRel because they liked being on stage, they liked writing blog posts. But it was very consistent that after like two to four years, you go back to engineering because no one can keep up traveling. Well, some people are really good at it, they'd travel the entire world.

You mentioned content, being on stage at a conference, that world also is kind of dying as well. There's less conferences, there's still the big ones. But I can't justify hiring somebody to go travel the world and pay for their plane ticket and hotel to give a 30 minute talk in a room full of 15 people in a hotel, or a conference hotel room. That kind of seems silly.

James: Yeah, the flip side of that too is that a lot of people believe that DevRels have to go to conferences. But I want to make it clear that DevRels in general don't have to go to conferences. It's more about what do you bring as value that is outside of engineering? Could you bring it in good feedback loops? Maybe you've done that as a project manager. Maybe you've done that before between engineering and other people in your company. That stuff is DevRel, but just done internally with internal customers.

I don't think people realize how many people outside of engineering actually do DevRel everyday, and you don't have to go on stage, you don't have to go and do talks, you don't have to make YouTube content, you don't have to make podcasts and blog posts. Some people do that, there are many different types of DevRel.

There's content, there is feedback loop people, there is all sorts of people, and I kind of bridge what I would count as the three types of DevRel which I basically do myself at the moment. That's just out of pure choice, those are the things that I like to do, so I just do them all.

Brian: Yeah. So any other things you wanted to mention about Clerk as we're winding down the conversation? I wanted to make sure we had time for picks.

James: Yeah. Come check us out, I guarantee you won't be disappointed. If you are disappointed, I'm the guy you can come talk to about it. I think we've changed how auth works in general, especially in modern frameworks. NextJS, React, Gatsby, Redwood, all of those things, you can have authentication in under five minutes. I guarantee it. Come check us out, and if you like us, stick around. I guarantee in a year we will have more features than you can ever imagine.

Brian: Cool, cool. So my quick question is for folks who already have authentication somewhere else, how easy it is to switch to Clerk today?

James: Yeah. If you have authentication already, come talk to us. We can do zero downtime migrations, we've done it with loads of different people. If you have Firebase and you're already on that, we have a guide that allows you to do Firebase. If you're on Supabase, if you're on Auth0, come talk to us, we have a bunch of engineers that will guide you through exactly what to do to go from X to us and we'll happily help you.

Brian: Perfect. Well, I want to switch us to picks. These are jam picks, stuff that we're jamming on. Could be music, food, technology related, all of the above. Definitely, have your pick. But if you don't mind, I'll go first, which I'm going to have a boring pick. My pick is going to be LinkedIn, which not what I would expect but I've actually, as a I guess now founder, content creator, head of product, head of sales, head of customer success, I've actually been using LinkedIn for a lot of experiments.

Back at my time at GitHub, I'd experiment pretty consistently on different platforms to figure out where conversions happen. Not to be a big brand or be an influencer in places, so I did TikTok for a while, I did YouTube for a while, I did Instagram for a while. Also did Giphy for a while. There's all these places you can test the waters and figure out if there's something there, and then build a program around it.

What I've been doing with OpenSauced is I've been doing two to three posts a week where I'll just do different types of frameworks. I got a list of frameworks of different posts that you do on LinkedIn, and I'll divulge in a future blog post and newsletter the more details about this. But one is obviously behind the scenes, a lot of people on Instagram do this where you take a picture while you're on this podcast, you're like, "Hey, did a podcast with James. Here's a story that I learned from James, here's a link to the podcast." And those do okay.

But the thing that works the best is career advice for obvious reasons, on LinkedIn. So during the most recent tech layoffs in the last couple months I did a very, I guess, simple post of like, "Hey, back in 2008 I graduated with a finance degree in the worst market and the worst job to have, and tried to do that." And it ended up getting quite a few impressions and it was a big conversion for getting signups for OpenSauced.

The goal was really to share my story and show that you can get roles through open source, was the post. I think if you're doing content and you're doing DevRel or if you're trying to build a product in the Jamstack, I'd consider looking at LinkedIn because the folks who are on there and engage are folks who want to be engaged with companies and engineers and other folks.

So yeah, that's my pick, try LinkedIn. There's some other stuff you can do like newsletters and live streaming and audio that make it... It's like the sleeper social network. I'm always impressed. I get like 10X engagement on LinkedIn than I do on Twitter, and I want to say I have a bigger following I have on Twitter. I don't even know how many followers I have on LinkedIn, that's the crazy part. But I get some crazy engagement over there.

James: Yeah, I love LinkedIn for that kind of stuff. You can do really well with especially career advice and things like that, and being open about... especially around now with layoffs in tech which is wild, by the way. That kind of stuff is super good for people on LinkedIn to understand that this has happened before, and it'll happen again, but here's some of the stuff that we've done over the past 13 years. Here you go.

Yeah, I don't have a boring pick, although maybe it is a boring pick. I don't know. Okay, so I'm a big VSCode user for years, but minimal plugins. I have three plugins, that's all I use for VSCode. Anyway, so Zed has finally come out into open beta. It is a high performance, multiplayer style code editor, I guess is the right way. It's from the people that created Atom, so it's super nice.

I actually just made the full switch, I've been using it for three works, no VSCode. It's super fast, it uses less memory, less everything than VSCode and it has an awesome collaboration tool where you can basically just click a button and invite your engineer into your code and you can start hacking away together. Super nice, check it out. It's Zed.dev, I believe is the right URL. Check out the beta, it's been awesome.

Brian: Yeah, I saw it come. I remember when it launched. It was, I think, mostly former GitHub folks because that's where Atom came out of. Yeah, I think it's also built in Rust as well.

James: Yeah, it is built in Rust.

Brian: Yeah, so Rust is the new hotness so go learn it. Actually, I will mention that Rust has really come along as a language. Twitter went with it back in like 2015, early days, pre 1.0, and a bit confusing for me because I didn't come from a C or a C++. Well, C would've been easier, but C++ I didn't understand the memory management and all that stuff. I think Rust has become way more elegant, so if you are like me and haven't touched it in years, definitely worth looking at it again.

James: Yeah, 100%. Rust is good, Rust is fun. If you want something a little different with more elegant memory management and some other stuff, it's worth checking out, especially now.

Brian: Cool. Yeah. Check out Zed for sure. Do you have another pick for us?

James: I do. One more, it's another tech one, it's Upstash. Upstash is essentially serverless data from Retis or somewhere like that where you can basically use it on the edge. It works really well with NextJS and you can also implement things like rate limiting with two lines of code. So instead of having to build your own rate limiter, you can use theirs using Retis, and it takes like maybe five minutes to setup and you can start protecting routes with rate limiting.

Yeah, it's really good. It's a great, great thing. I don't think they get enough love in the industry, in our space right now. But they're really one of the easiest and fastest ways to do things like caching and rate limiting. Definitely check it out.

Brian: Perfect. Yeah, I definitely looked at it a couple months ago, I think I saw it on one of Theo's live streams. Yeah, it's not a problem I'm solving directly because I now hire people for that. But yeah, it's definitely a thing that's on my radar and if I ever want to start from scratch again and build my own servers I'm going to connect that to my NextJS app.

James: Yeah, absolutely.

Brian: Cool. Well, James, thanks so much for coming through, talking about Clerk. Folks, definitely check it out. I think the development in the last couple of months has been amazing. Also we didn't even talk about Clerk being tweeted out by Nat Friedman recently as well, and getting a ton of exposure that way. So everyone, go check out that tweet and what Nat's building.

James: Nat.dev, everybody go to Nat.dev.

Brian: Yeah. Go authenticate and login. I don't even know what he's building, it's some sort of AI. Probably some AI thing or whatever.

James: Yeah. It's like an AI thing and I checked it out right in the beginning. They're working really hard on it and we see a lot of spikes in traffic every week. He's having a good time, he really liked Clerk and it took him just a few minutes to get it started so it was great.

Brian: Yeah, amazing. It's nice to have that experience which you're working on, that zero to dev experience. So folks, if you followed me for a while and have seen my previous Heavybit talks as well, I'm all about onboarding and if you can onboard... I say that with the caveat, onboarding with OpenSauced , not great yet. We'll focus on that eventually. But yeah, onboarding, as soon as you hear about the product, how quickly can you be behind the driver seat? That's an amazing experience for Clerk that y'all are providing.

James: Yeah. Thanks so much for having me.

Brian: My pleasure. And listeners, keep spreading the jam.