Ep. #140, Accelerating API Development with James Perkins of Unkey

Brian Douglas: Welcome to another installment of Jamstack Radio. On the line we've got James Perkins from now Unkey, Unkey.dev. James, how are you doing?

James Perkins: I'm doing well. Thanks for having me back for the third time now. I just should get residuals at this point, I think. But yeah, good to be here, love being here, love chatting with you every single time.

Brian: Yeah, it's a pleasure. We crossed paths originally I think from your YouTube content/your livestreaming as well, and then you had just took a job at Tina. Went from TINA to Clerk as a power user to helping out with DevRel, to now working Unkey.

I'm very interested about Unkey because this has come up multiple times in our Slack channel internally, it was like, "Oh, let's check this thing out. What's the use case?" And I'm really excited to learn about the use cases for it, but want to start with what is Unkey? That's probably the best place to start at.

James: Yeah. So Unkey is essentially unlocking API authentication and authorization for you, as a developer, to give to your end users. So let's say you have an API that you want to put out into the world, and as soon as you do that you need API keys to issue to an end user who can then use them. Whether it's a developer or whoever. The problem with that is it's really hard to scale that globally, so if you start getting users in Europe and you're in the US, how do you do all that kind of stuff?

So basically we provide you with keys that are globally distributed across the globe that you can add specific things to, so maybe you want rate limiting on some keys, maybe you want your keys to expire in a week or a month or a year, you can do that.

We have ways to revoke those keys, we have ways to update those keys. Essentially it gives you this all-in-one built in API-first product that, at the end of the day, as soon as you sign up, within five lines of code you can start issuing keys to end users.

Brian: Is this a pain point that you've felt yourself or how did you discover this?

James: Yeah. So I can't take credit for the actual product. My co founder, Andreas or Kronarc as he's known around Twitter and GitHub and everything, approached me when I was at Clerk and he was at Upstash and he had brought this product idea up and said, "Hey, we should do co-marketing, we should use Clerk and we should use Upstash, we should do it together and then we can do some co-marketing.

Maybe do a blog on each blog and we can share it around." When I heard the problem I was like, "We should just build this. This seems weird, we should just build this product." Because yeah, I've built many APIs, public facing and privately facing, and ones that interact with thousands of other companies, and the biggest pain point is how do you securely issue an API key?

How do you make sure it's fast for whatever users are using it? And how do you track analytics around that API key? How do you know if this person is using it 200 times more than the other persons? Right? All that stuff comes up.

Every time I've built it, I've always started from scratch and built it. Andreas, same way. Built it the first time from scratch, then the second time copied and pasted the code, modified it a little bit more, make it kind of generic. Then the third time he went to do it was when we started Unkey because we were like, "What's the point? We should just build this instead."

Brian: Yeah. This is something I guess I had the benefit of working at GitHub and using their experience, which I think one of the most valuable things I got a bunch of keys that I'm basically spinning up a quick, little side project. I built a bunch of CLIs to support my role at GitHub, which kind of look like Open Sauce to be quite honest.

The cool thing about that is it tells you the last time the key was used, so if I build something and I'm like, "I don't know if I should just wind this down, this bit of exposure," we'd also have some security checks and reviews based on what had GitHub Enterprise access and what didn't. So anything that had GitHub Enterprise access had to have an expiration, but then I didn't know if I had to regenerate and go find out where they were used which becomes an entire pain point in itself.

I consider myself a power user of GitHub, basically, even as a non-employee at this point. I have a bunch of keys that I don't know what I'm doing with. We also have an interaction, and this is what excited me about Unkey, is that Open Sauce has an API as well and we generated a JWT, actually today.

So not a proper, full on key, but the JWT is the same as your auth token and that's what you use to interact with our OpenAI spec to go test some data in browser or to go build on top of Open Sauce which very few people outside of us are doing. But now I'm interested because if we wanted to build out that experience and develop our experience, it seems like Unkey might be the thing we want to grow into.

James: Yeah, and that's the idea, right? Is that maybe you start building your API and, like you've done, you've used this JWT because you already have that and so it's easier to pass that around for now. But there's a point where, yeah, you want to build a great DX experience where you're like, "Hey, build on top of Open Sauce, give me your API key plus some data and I'll send it along," and that's how we can do it.

It's one API call to issue the key and one check to see if that key is valid, and if it's not valid, you just reject them and if it is valid you can continue on and our response time is super fast. Our slowest times are about 30 milliseconds.

Brian: Oh, wow. That's amazing.

James: Yeah. So we're super fast.

Brian: Yeah. So for whatever reason, we've had a lot of maintainers and founders of companies as of recent on the podcast, and I want to actually just dig into a bit of your founding story of Unkey. You mentioned your co founder had built this already once before, had built it again.

But I'm curious, as you were building this in the open, you had a full time job and a role at Clerk so, curious, as you discovered the problem how were you maintaining the day job but also scaling this open source fun, side project to eventually make it a company?

James: Yeah. Lots of late nights, lots of weekends, which is the classic. Yeah, so we both had an agreement that we'd only work part time and we'd work weekends and that would be it, and we would try and keep Unkey just ticking along. The initial part when we built the initial part, it happens in June and I happen to be off of work for a couple days and Andreas is in Germany so he would finish work and then I just happened to be online.

So we spent a big spike of our initial first NBP just in those first five days. That was almost ready for production at that point so then we just fixed a bunch of stuff and moved on. But as we started to scale, it was very, very hard to be like, "I have Clerk and I need to do a minimum of 40 hours of Clerk," and I was always doing 50 hours and I treated Clerk kind of like I was part of the founding team.

Then I had spent anywhere from two to four hours or even more every night working on Unkey, fixing bugs or trying to figure out how the strategy works or making the marketing stuff flashy enough to announce. It was very hard and there was a point right before I left Clerk where there was a tipping point and I guess maybe you had the same thing when you were at GitHub where you just realized that...

I love Clerk and I love the product, and it'll always be somewhere in my whatever, I'll always recommend it. But there was a point where I cared way more about what Unkey was doing than I did about Clerk's success. So I was at this point in the road where it was like, "Well, I care about Clerk's success, but I care way more about if Unkey is going to do something." And then that's really where I knew that we were on the right road, and we had already had talks with VCs and we'd already had talks with investors about, like, "Hey, we want to invest or we could be investing," at that point.

Brian: Yeah, at that point you had only a handful of months in. It sounded like you figured out the MVP early, you started getting a bit of adoption and some folks noticing you based on... I would notice a few tweets from you and your co founder every now and then I'm like, "Oh yeah, Unkey can do this." Or, "Here's our new website," when you had your landing page launched.

It was pretty nice to look at, I had better understanding of what the product was. So did you raise money before quitting or did you go ahead and quit and then go get some checks?

James: Yeah. So we had checks inline already before I had left Clerk and before he had left Upstash. We had already raised over a million at that point, so we knew we had checks in place, so at that point it was like, "Well, we're already in this. Let's just do this kind of thing." Because, as you know, VCs don't invest in people that are doing part time work so you've got to be all in.

Yeah, we'd already raised over... it was like 1.1 at that point and we were really ready to go already but tying loose ends at both jobs and making sure everything was inline before we left.

Brian: Yeah. I forgot that your co founder was at Upstash too, which is another up and coming Dev tool startup as well. Yeah, how did you guys meet originally?

James: Through Clerk. So if you know Andreas, he is a serial builder, he's built a bunch of different side projects over the time and he was working on PlanetFore which is way to test global latency for APIs, a common theme. He was building that and it was right when I think it was last NextJS Conf, so not this one that just went but the one before when it was App Router announcement, all that kind of stuff.

Clerk supported it day one of App Router or it was like a week after or something like that. He was one of the very first people that wanted to use it and it was buggy and it wasn't perfect, so he had come into Discord and started chatting and ever since then we pretty much became friends. Then I did some work for Upstash and we just kept in touch ever since.

Brian: Excellent. And who were the folks who were earliest, I guess, users that came onboard? Are these folks that represent companies and developers that had to maintain APIs?

James: Yeah. So it was an interesting spread. We had some just AI builders that maybe more indie space where they were like, "Hey, I want to build this cool, new AI project but I also want an API to be able to interact with."

They were our first real sets of users because building on AI is really easy until you get to the point where you need to have some sort of API, and then it becomes a bit more complex.

So we had a lot of those, and then our biggest customer who's still our biggest customer today is Premiere who are a crypto trading platform. They built an API that essentially allows them to whitelist their own product, so they can now go and say, "Hey, you want to be broker of your own or you want to work in a brokerage and you want to be able to do these crypto trades on the fly instead of through a UI?"

They had a bumper month last month, they did like 10 million verifications last month, which is huge in comparison. I think they did like 100k the month before, so it was this dramatic increase and it was a bit of a, "Are we ready for this? Well, I guess we'll find out now," because they're pushing two million a day right now.

Brian: Wow. They came onboard before you raised funding then?

James: Yeah, yeah. Basically we launched June 21st, we launched pricing July, I think it might've been 4th of July or just after 4th of July and they signed a contract with us like three days later.

Brian: Okay. Wow. This is an amazing trajectory of zero to a two million invocations, activations or whatever the term was. But yeah, I'm absolutely fascinated. If you look back since July, would you do anything different at this point or do you feel like this is a nice Cinderella story?

James: I think we may have done some things differently. I think there was a lot of just the blind leading the blind. The product itself, we're both serial builders so building the product was the easy part. It was everything else, except for marketing. Everything else was hard.

I definitely would've probably spent more time talking to other founders about like, "Hey, how do you do this? Because this is wild." Everything that comes along with raising money and all that kind of stuff, and then when you raise the money it's just more paperwork and even more paperwork, and less time building.

But as a product itself, I feel incredibly lucky every day that, one, we got some adoption from some people and, two, that that adoption rate, although paying users is not as high as it could be and we're not really caring about that right now, we're more caring about people just trying this out, we still have people in the pipeline right now that are fairly big.

Either fairly big startups or fairly big personalities, I guess personalities is the right word. People that if you saw, "Ah, Unkey is associated with this person," you'd be like, "Oh, maybe they are legit," kind of thing. We have a few of those in the pipeline too.

Brian: Yeah. I can only speculate on what companies and who you're talking to. I definitely want to have Dub.co on, Steven Tay. He's just recently putting together an API, I think only in September I think. I know, because we've been using it and we're a paying user of the Dub.co URL service. But I imagine even that as an interaction, to be able to say, "Okay, we want to have a white label experience of generating..."

For Open Sauce we have charts and graphs and a bunch of data, how do we white label this experience and use our data, but also be able to pipe in some generating tokens and keys for Dub.co? I mentioned before we got online the experience of OpenAI is also pretty underwhelming when you really start embedding this into your products.

I was using TablePlus today and they had these cool little Generate SQL Queries inside of this SQL ID. I'm not a database person, data engineer, but TablePlus is like the ID to connect your PostgreSQL connection but they have this little side panel where you can chat and say, "Hey, based on this table, generate a query that does this. The context is I'm using time series and blah, blah, blah."

And it generates stuff. Pretty cool, but I hate to generate a token to OpenAI, paste it in OpenAI, and then hope for the best that I remember how this works and nothing is going to be leaked or anything like that. Honestly, yeah, OpenAI's side, I don't know.

It tells you the last use, but it doesn't really give me a good way to generate, spin things up and spin things down on demand, so I can imagine obscuring that part of the feature into some developer experience because the manual process of generating a key as a user, pasting it in, hoping for the best...

James: Yeah. It's kind of crazy that that's how AI went, is that, "Yeah, just paste another OpenAI API key in here." It's like, "Okay. I'm giving you my secrets, basically. I'm willing to paste in this secret that costs me money to do." That's one thing that we're targeting in the middle of January, is helping AI developers build this secure API that they can use.

You have options, right? Just charge your user per usage or whatever it might be, and then pass it through your own API key. Or if you want to have them have this interaction, make it seamless. One of the biggest things is token based generation is a huge thing, where if you have ever used RoomsGPT, for example, which was a really popular project for a while where they gave you three tokens and then you can generate three rooms and if you want more, you pay more.

That piece of AI is so complex for people today because they have to build in, "Okay, I've got to build my project. Now I've got to figure out how do tokens work, how can I build tokening into my system? How do I charge people for this?" All these things are really complex, and we're targeting that in January to simplify that whole experience, where essentially you can create a key that has a remaining amount.

So let's say 100 tokens. Then you can then have it automatically refill on a schedule. So every month, someone pays you for 100 tokens. Every month we'll just refill it for you, so all you have to do, you don't have to worry. Just, "Boom, I've given you this key, it's going to refresh back to 100 every month. You don't have to worry and all that is there."

We have half of it now where remaining exists, so you could do that today but you have to manually update the key every month. But in January, we'll have this new feature where you can essentially set daily or monthly, "Please refill back to 100 every day."

Brian: Yeah. As you're explaining this, even the thought of... So you mentioned the analytics and usage, we've been long time OpenAI users, since they've had the API available to be leveraged I've been tinkering around with it. Before the pricing changes of the summer, it was like maybe $5 a month and now it's like 25 cents a month based on our users and usage.

What I'm getting at is I didn't know what that was going to look like before I added the feature to Open Sauce, so you got VC money so you're just hoping for the best, making sure it doesn't break the bank. So it turned out that it didn't break the bank based on the one feature we have that uses OpenAI right now, but the reservation was like, "I don't know if we want to put too many features because we don't know what the usage will look like, how can we gate this?"

But if we were able to generate tokens on demand and then have some sort of insight that says, "Hey, someone hit the limit," there's an opportunity to say, "Hey, you've hit our paid tier. Here's a conversation we can start." Today kind of hard to do without constantly opening up the platform of OpenAI.com.

James: And then looking at that specific one and figuring it out. Yeah, all that goes away.

Brian: Yeah. And then overlapping based on usage data, what user is actually overusing something. Yeah. It'd be nice to just know this off the bat.

James: Yeah. And with Unkey you can set... The way that Unkey kind of works is you have a workspace and inside of there you can set APIs, however many you want, it's unlimited so you can set prod, preview, development, or maybe it's very specific to routes if you want to be really, really specific to maybe a feature, for example.

Then for each API you have your set of analytics for that API, that's for every single key. Then if you want even more analytical data, you can actually go in and look at the per key request and see which keys are doing what and when are they doing it, when are they most busy, how many are they putting in a month, seven days. All that stuff comes along out of the box and doesn't cost you anything.

Brian: Excellent, cool. Yeah, so if folks want to get started with Unkey, what are the steps?

James: Yeah. It's just sign up for a free account on Unkey.dev. Once you've signed up for an account we take you through an onboarding experience essentially that shows you, "Hey, we've created your workspace. Go ahead and create your first API where you're going to keep all your keys. Create a route key," and then we give you a little call command that you can test to see that it works, and then we also do one more piece in our onboarding that's basically like, "Hey, check out what happens when you try and verify the key that you just made."

You do that, and then after that it's either you can use our API directly or you can use an SDK, for example, if you're running NextJS or a TypeScript backend. It's as easy as installing Unkey/API, and then it's two lines to verify, two lines to issue a thing and you just decide how you want to implement it yourself, serverless, server, however you want to do it.

Brian: Is it language agnostic or is this a Typescript thing?

James: Yeah, it's completely agnostic. We have SDKs for specific languages right now, so we have Rust, we have TypeScript, we have Go, we have Python. We have a bunch of different ones. But the API itself is just a simple Rest API that has an OpenAI spec so you could even generate your own SDK if you prefer, and have it in the language of your choice.

Brian: Cool. Sounds good. Yeah, definitely going to put this on the pipeline for Q1, Q2 for us to take a look at, for sure. So I will be in touch, for sure. I hope, folks, if you're interested in maintaining your APIs for the developer experience and for your users, definitely check out Unkey.

James: Thanks, appreciate it.

Brian: Yeah. So we're going to transition to picks, you've been here before so you know the road. It's stuff that we're jamming on, could be music, could be food, could be entertainment, tech related, and I will go first if you don't mind.

James: Absolutely.

Brian: Actually I had a pick quite a few years ago, which was the June Oven, which is sort of a machine learning empowered oven, desktop oven that toasts bread but can also proof your sourdough and you could roast an entire turkey if you wanted to. Well, a small turkey. Been loving this device, but as with almost all software it has an end life. I wished, based on the cost of the thing, it didn't have an end life of four years but here we are.

The company itself got acquired by Webber Grill which means almost everything about the product and everything is just absorbed into Webber products which kind of sucks because it means that my product is literally end of life and it's basically broken. So I've been in the market of toasters, because the thing I used the oven for, ironically, a $600 oven, all I do is toast bread with it.

It doesn't matter how much tech can be involved, if it can toast bread that's all I care about. So I've been actually rethinking about my entire life and simplicity, and trying to buy a toaster is actually quite interesting. You go to Target and there's a bunch of options and some have... I definitely am never going to have a digital toaster ever again because why? I just need it to make sure the toast doesn't burn.

I don't actually have a pick of a toaster but I have a number of toasters I've been reviewing. Funnily enough, Wired has the toaster reviews. It's been a fun process to look at such a simple device that, first principles, does the bread burn or does it not burn? That's the answer you can ask and you can go from a $20 toaster to a $200 toaster. It's pretty ridiculous, but I'm having fun being in the market for a toaster.

I'll probably buy one in the next day or so, and I'll report back on which one I chose. I don't know. The Cuisinart is the one with the four bed toasters because I've got a family of four so we all need our own toast at the same time.

James: I could see that being a big challenge. I don't eat breakfast so I don't have this toast problem. I did have this toast problem when I lived in the UK and I went through loads of different toasters.

Brian: Lots of beans on toast growing up?

James: Yeah, exactly. Yeah, you're right. A lot. Even when I was an adult, it's cheap. But yeah, talking of picks, I have a thing, it's in the similar vein that I always like to bring up which is I have Tovala, which is also in the smart oven space because I'm also bougie like that, I guess. Essentially what it is very similar to the other kind of oven.

Essentially it has a QR code scanner on it and it also has a web app that's built in, and what it does is allows you to essentially cook things to perfection, is the idea. So you could put chicken breasts in there and just click a button and it'll be like, "These are going to be perfect every single time." And on top of that they deliver meals that are less than three minutes to prepare and less than 30 minutes to cook in that oven.

I use that because it's just me and Abby and that's it, so we use that. It's the best experience ever. It comes every week. You take it out and it's got those little aluminum trays and you put a bunch of ingredients in, you scan a QR code and every single time it comes out cooked to perfection. It makes really good toast. Not really helping you, but it does make really good toast because it steams the bread as it toasts it so you get a nice squishy in the middle and crisp on the outside.

Brian: That's quality right there. I think my wife would hate me recommending another smart toaster, but I'm actually intrigued. I am intrigued by the whole meal planning portion of this as well. James, do you might've ruined my entire toaster shopping experience.

James: Yes! I've done it, I've done it. Yeah, convert one more person to Tovala, that's my thing.

Brian: Excellent. I'll get your coupon code.

James: There you go, there must be a referral code somewhere.

Brian: Excellent. Well, appreciate the pick. I don't know if you had another pick.

James: I have one more pick, which is actually tech related, and maybe more for founders than anybody. It's called Rise Calendar which allows you to basically put all of your people on a calendar so that you can see everybody, including timezones because timezones are really hard in general. They're even harder when you've got someone in Europe and then East Coast and it makes it really complex.

Essentially what it does is it does two things. One, it allows you to see everybody's timezones and figure out what's good. Two, it allows you to do these flexible meetings. Andreas and I meet every week, but it has this flexibility so if his day or my day fills up with stuff, it'll just move it and send the new update. It'll say, "Hey, hey.

I know we were supposed to be at 8:30 in the morning but we've moved it to 7:30 because that gives you a block of time to keep focused." And it also will actually put on your calendar focus time if you get too many meetings in a day so that you have enough time to actually do anything.

It also allows you to share a meeting invite with, say, maybe you need to meet with an outside person and it has to be three people on your team, it will create a link for you with all of everybody's calendar and figure out when really good availability is and it will send a link with that availability only so that you don't have to have the problem of like, "Well, we put this on a calendar but that's Mike's lunchtime," somebody's lunchtime and now they can't have lunch because they've got to have this meeting or move it around. It's free, I think it's free up to like five people on a team.

It's really great, it's helped us keep some of those meetings away so that we have focus time so that we can actually do stuff, even when those random meetings crop up that you didn't expect.

Brian: It's funny, I remember this being a thing, post-Calendly time. But in between now and then when Calenly showed up, huge pain point and I'm very intrigued. I'm glad you shared this pick because we do have folks in different timezones and this would actually be super helpful as we coordinate scaling the team up.

James: Yeah, it definitely helps with that. It was one of the first things that Andreas and I did was, "Hey, everybody gets a Rise account because I don't have time to figure out what timezone you're in and what time it is there and all that stuff." It just shows up, it's great.

Brian: Excellent. Well, appreciate the pick and I appreciate the chat as well. Listeners, keep spreading the jam.