Paul Klein, CEO & Founder of Browserbase

People who are perceived as visionaries, it's often like revisionist history. Like, I imagine that Patrick Carlson, when he started Stripe, didn't feel like a visionary. He was like, we're just going to make payments, work online and then like increasing the GDP of the Internet. Like, I think that probably came a little bit after they started solving the problem.

I think most of us have someone in our life who every time we speak to them, we feel like we really should raise our game. For me, that might be Paul. Today's guest. Paul sold his first company to MUX, the video API, in 2021, and worked at Twilio in the really early days as well as MUX after the acquisition. And Paul founded Browserbase in January 2024, which was also the same time that I met Paul when he was writing his first lines of code for Browser Base. Browser Base is a browser automation dev tool. So for all the people building agents, they need infrastructure for their agents to be able to go around and do stuff on the web. And they've grown like crazy. In June of this year, 2024, they announced that they raised six and a half million dollars. And the other crazy thing is that every time I spoke to a vc, they would say that the company they were most excited about was Browser Base. So they really struck this chord. And a lot of people are excited about Browser Base. So the obvious question is, how has Paul been able to go from zero to where they're at now so quickly, as well as how have they been able to create that excitement, especially around investors. We also talk about how to hire, including how to hire your friends. We talk about what to look for in your hires for DevTools. One thing to stick around for that, I think, is the most interesting part of the conversation is how Paul prioritizes things and some of the things that he doesn't prioritize, not many people are willing to talk about that. So I find that really interesting. It's a really cool episode. Enjoy.

You know, you saw Browser base day, negative 10, I would say very, very early days. So it's kind of cool to have come full circle and now be on the pod. I'm excited.

Yeah. And it's kind of crazy because I remember, I think when we first met, I was like, I made this little script that would book badminton calls for me and it was like, surprising how, like, how annoying it is to work with browsers.

And so, yeah, that's a canon event, right? Like, every developer early on in their lifecycle actually wants to automate some sort of tasks that they do. And it means they have to go out into this rogue Internet and load a webpage, click a button, fill in a form, and they use Beautiful Soup. They're writing some hard coded stuff, and then as soon as they want to, like, deploy that, they can close their machine. Yeah, we always work on your machine, right. It doesn't work on Amazon for some reason. That's something that I think is just so core to every developer's experience. And that's where browser comes in, because we make it so you can deploy these browser automation scripts to the cloud and have them run reliably without having to replicate everything that happens on your local dev environment.

Yeah, it's very, very cool. And I guess you already felt this was like a thing, right? And then it seems like it was like seeing the rise of agents has kind of like, was that like your. Was that like an aha moment where you're like this, I have to build this?

Well, I always knew that this particular piece of infrastructure was a painful thing because I spent my time as CTO of my last company just nights and nights and nights digging through old stack overflow questions, learning how to find the right font driver to make emojis work, or why, you know, certain things weren't working in the browser for this version of Chrome, they were work in this version. So I felt that pain and I was just really unhappy with the tools that existed out there for running this kind of stuff. And then it kind of became more clear to me this would be valuable because I made a small SaaS application during 2023 or so, which was actually logging in and helping Airbnb hosts automate their messages. Not many people know this story, but kind of like a nights and weekends project. I built this business called Guest Guru, which was a Airbnb chatbot. It was super early on in ChatGPT, and part of that workflow required logging into Airbnb and responding to messages because there was no messaging API we could have access to. So from that I pulled out my old browser automation knowledge combined with an LLM and it kind of clicked for me, like, oh, this is actually going to be a really common primitive for other people who are building AI applications or AI agents. And from then I just did a bunch of other conversations with other people who were building, and this was something that always came up as a top three payment pain point for them. So it felt really clear to go start the company. I quit my job on the same day someone told me, hey, I would pay money for this right now. Sounds good. I'll walk back into the office. I think they were having a board meeting that day, which is a tough time to quit, but they're very graceful about it and they're supportive for me to go start this company. I always said that the only company I would start again would be a headless browser company. That's all I know about from my time at Stream Club and that's the one I'm starting now.

That's very cool. Um, and if you had to put your finger on like how you've been able to like kind of grow so fast in the first eight months of browser base, like why that's beamed. Okay, quick announcement. WorkOS are hosting a one day conference dedicated to enterprise software. It's called the Enterprise Ready Conf and it's taking place on October 30th in San Francisco. They have got the founder and CEO of Vanta, Christina speaking as well as the head of product for ChatGPT. Yes, ChatGPT. Brit. So if you've got questions for them, go along. And they've got their founder of workos, of course, Michael Greenwich, who's been on the show twice and you know how much he knows about enterprise software. So if you're kind of thinking about, you know, selling enterprise software or you already do it, you should definitely check out this conference. Go to enterprise ready.com or click the link in the show notes.

Yeah, I think the growth to like the majority of our customers are actually people who built this on their own. Like we really tapped into the pain point. Like people who have built and maintained this stack on their own and they're like, screw this, I don't want to. Or these competitor who really, they haven't really innovated on that side.

Is that because it's more for testing rather than.

Yeah, I think a lot of the tooling is built around testing. I also think that generally the people who've played in this space have been more bootstrapped companies or people who've been like one of our biggest competitors is run by a single guy with a bunch of contractors and the dashboard really hasn't changed since 2019. I was a customer of theirs until I built Browserbase. So I think that they were just kind of dissatisfied with. They had this complex piece of infrastructure. They wanted a vercel or clerk like experience for managing this, but no one had really stepped up to build a product level that would match that. And I'm really lucky that I, I was building for me. So I knew exactly the features I wanted to like. Our first, our roadmap to this date is still the stuff that I think that we should have had on day one, that we just haven't had time to build yet. And by delivering on that and also like evangelizing the problem a little bit, I think that we've been able to win over the trust of quite a few customers, especially startups. And I remember when I was CTO of my startup, the way I decided about buying SaaS or Infro, I'd ask other CTOs, what are you using? So this year I really focused on making sure that I was talking to all of the SF AI agent builders and application builders and making sure that they knew about us and they were choosing us. And if you win SF, I think you win a lot in AI right now. So it's lucky. I've been here for 10 years, so I already know where everyone hangs out. Southern Pacific Brewery. That's it, right? That's the only spot.

Maybe that's a good aside. Is like, it's funny how the marketing and SF is almost like kind of like small town marketing in a sense of like people have billboards and it's very like event driven in this, not in a technical sense in like literally running events and meetups and stuff like that.

Yeah, everyone knows each other here, which is really. It's like, it feels like Twitter is a lot bigger than it actually is, but at one point you start ending up on market maps next to people who you know the other founders, and you send them like, hey, look good to see you. Or someone will say, hey, watch out for this list of companies. And I'm like, no, these are all people I know, right? It's a small town. And I think that also means that your reputation here carries with you and you have to be mindful of how you treat your employees, how you treat your competitors, your customers, because people don't forget that stuff here. And I've really prided us at Browserbase on being just really good to our team and really transparent to our customers. And we do things like we had a short window of decreased performance and we set a company like a slack blast to everybody for something that I think a lot of the people would have just swallowed and not talked about. We're trying to be super transparent about what doesn't work because that's really frustrating as a dev, when the thing isn't working, you don't know if it's your code or the vendor's code. From day one, we want to try and be really transparent about what's going on on our side and what's going on on your side and helping people figure out why is this thing not working.

Yeah. What kind of stuff were you saying? And not in specifics, but when you talk about. You said decreased performance.

Yeah. So there was a six minute window where session creation was slowed down and we said, hey, here's what happened. This is the start time, this is the end time. This is what you would have seen. It's resolved now and we're postmorting it.

You put that in the community stack?

Yeah, we send it to everybody just because we want to be. I think you could have just put that in a status page page and hope no one noticed it. But we wanted to be really explicit with communication.

Yeah, that's really cool. Okay. So you're growing very fast and you're building the roadmap of what you wanted, basically. The other thing that I think that you've been doing is I think there's this. People talk about hot companies and I think browser bases. Definitely.

Very, very. We definitely have VC market fit, for sure. Yeah, that's true.

Yeah. And I was kind of like reflecting on why from an outside perspective and trying to think a lot about this. So I kind of want to ask you that as well because I think it's always kind of two sides to this. Right. It's like pleasing customers and then also being able to raise the capital that you need to grow the business. What do you think you've done really well on?

Yeah, I think we just had a really clear narrative like we always knew. We always knew we were going to do from day one.

Yeah.

I even wrote about. I wrote like a 3,000 word long form memo around like, here's what the problem is, here's how we intend to solve it. Here are the risks, here's the bets that we're taking. And. And I published that three months before we even started the company.

Yeah.

And I think my story really aligns with the company. You know, I started my career at Twilio. I was actually an intern during the ipo. So I got to see like a best in class infra company start there. I did Stream club where I learned about headless browsers. We sold that to Mux, who is another just amazing infra company with great infra founders.

Yeah.

And from all of that there's like this really cohesive story that like I should go build an infra company. I've been at two of them. I was CTO of A company that had a lot of relevant experience with headless browsers. And it's just a problem that really aligned with my story. And I think people also saw the same world playing out that I did. The future of software isn't just software making you faster at what you do. It's software doing the work for you. And if software is doing the work for you, it means that you're going to have software go out and browse websites using a web browser, just like we do when we're doing work. And if we can help power that in some way, I think that's just a really powerful place to be in the future of software. And to me, that future seems really clear.

Yeah. And because it was kind of funny, we were talking before and I was kind of putting you in this bucket with, I would say, like Michael from work OS is really good at that as well, of having this vision. And then you were like, really? I see myself as like the anti visionary. And we were talking about it and it seems like it's like you don't see it as like a vision. It's like you believe this thing, you believe you have a worldview on the future and you don't see it as like vision. It's like you believe that or you know in your mind that agents is going to be. Are going to be like a very disruptive.

I think it's like people who call themselves or people who are perceived as visionaries. It's often like revisionist history. I imagine that Patrick Carlson, when he started Stripe, didn't feel like a visionary. He was like, we're just going to make payments, work online and then increasing the GDP of the Internet. I think that probably came a little bit after they started solving the problem. But he probably looks like a visionary now. I mean, he's an amazing founder. I think same thing with Jeff Lawson. He's like, these telephony APIs don't exist or they're painful and I want to send a text and that would be really helpful. I think there's always this aspirational vision, but I try not to get too distracted from what we're doing. We're solving this immediate problem. We have ambitions to continue to solve it in better ways and make it easier for developers. And to me, that's an endless optimization game. We can infinitely make the infrastructure better, more affordable. We can actually move up the stack and solve the customer's problems in a more reliable way at the SDK layer, maybe even higher than that. So it's just More of a pursuit of solving a problem to perfection than it is like I want to become Elon Musk in this vision. I just really love the problem we're solving and I think it has a place in the world.

Yeah, it's really, really cool. For me, if I wanted to go the VC route, I would want to feel as sure on a problem as you are. If you just wanted to write a function that calculates something, it's easy. But then as soon as you bring in it has to go get some number from some website.

If I want to download my bank statements, I have to go buy Plaid or integrate with Plaid. I can't log into my own bank account to click the button. Wells Fargo doesn't have an API I can use very easily, but I should be able to just log into my bank account and download those things in an automated way without going through this whole rigamarole. So yeah, I think that what's really exciting me about Browser Base is that we have a chance to be a category defining company, which means we are early to a category that is going to be more important in the future and we can be in front of that category. And that's the best type of infrastructure business to build because you get to kind of pave the way a little bit and there will be people who copy what we do or compete with us. And I think that's fine. That's a really big market. I actually don't. I think anybody who worries about competitors before $10 million of ARR, they're probably going to lose for other reasons if they can't get to 10. So it's not something that keeps me up at night. But for us, I'm excited about using our firsthand knowledge of dev tools and infra and the things that we love to use on other systems. And how do we apply those same principles to browser automation and automating the web? I just love to give developers more sophisticated primitives to use and more sophisticated tools. So programming becomes just an expressive thing. With browserways, I think we're doing that by letting people write code that controls the Internet.

Yeah, it's really cool. Okay, so you're at Twilio and then you built Stream Club, a devtool app, Mux, a dev tool. Browser base is building tools for developers. But I guess in particular it's like AI engineers would be one categorization. One of the questions I had for you is it do you feel like it's different the audience that you're building browser Base for versus the audience that you were kind of like the type of developers that you building browser base for versus your previous experiences.

It's actually, it turns out engineers buying AWS and engineers buying browser base have the same questions, right? Like will this infrastructure work? Like how much is it going to cost? How reliable is it, how does it scale? So it's very much like an infrastructure business. And right now one of our target segments are like these new AI companies because we know that they need help right now to get to market faster to launch their thing. So they're willing to adopt and use browser base. There's a huge category of developers who aren't doing AI that actually also need browser based and headless browsers for a variety of data retrieval tasks. Browser testing, just traditional RPA that doesn't use any AI at all. Rpa robotic process automations like Automate, something with Playwright. So the customers aren't very different. I think that what we've done is just really tried to serve these startups that are just getting started because this is when they're making their fundamental infrastructure choices. And what I think about is every time we add a cohort of new customers, how are they, how is their revenue going to grow over the next 12 months? Right. And what's nice, like maybe like the first couple weeks, not going to be a huge customer, right. They're just building their thing, they're getting started, they're going to launch. But as they grow in, find product market fit, we get to grow with them. Which is the most beautiful part of info businesses is that you win when your customers win. So I try and do a lot, like I'm reviewing YC apps of some of our customers right now, right. Like doing everything I can to help them move along as well as like some of our larger customers. Like how do I help them navigate the procurement process so they can get to buy browsers faster? Their internal project they're trying to build to prod sooner.

Yeah. And how are you spending your time right now? Because you're also. That's another thing is that you're a solo founder, which is. Yeah, that was a visceral reaction to that.

Well, I'm happily married, so I co founder for life. Julia does a lot for me. So I would not be able to do this without an amazing spouse. I've also just been able to hire really great people. Like my first manager at Twilio is now our head of engineering.

Really?

Yeah.

That's super cool. That's so cool.

One of the people I work with At Mux on the browser stuff I did actually, that works for us. We just hired our designer who worked with me at Stream Club. So we're reassembling the DRE team. It's a lot of people I worked with before who I want to work with again, and we're able to get.

Them to come join us.

Being a solo founder, I mean, I spent the first third of browser based building the product. I built the whole product with some great contractors we brought in to help us as well. The second third was really kind of putting the team together and we built this amazing core team of infrastructure engineers. And then the current third that we're in is really scaling the company and preparing for. I think 2025 is going to be a really big year for us and I think we're starting to see signs of that, especially as foundational models become better and better. Cloud 3.5sonnet has unlocked a lot of really interesting use cases and I think we'll see that more with an evolution of foundational models. So we're really thinking about how do we prepare to scale the company and we have a PTO policy now. What does it mean to take time off? We have an expense policy. I'm not the only person managing all our expenses anymore. So we're trying to hire and really put in place the things we need to scale the company so I can kind of move into this place where I can actually do the highest leverage things. It's probably not the best use of my time right now to take our Amazon bill and put it into ramp. It's probably a better use of my time for me to be really nitty gritty in the product docs and giving feedback on how this feature should work and hopping into customer fires and helping support them when the team is busy. That's the best use of my time is like making the product better and helping customers. So I'm trying to hire more great people to help us scale browser base. And for us that means like building out a team on the go to market side. Like we have our first sales engineer starting. Sophie's going to come in and she's going to get on all the customer calls and help support them so I can maybe skip a few customer calls in the future and that'll be okay because she's going to do a great job.

Yeah, that's, that's super, super cool. How is it like hiring your friends? Is it like, do you have any tips for people that are like, I want to hire my friend?

Yeah, I don't know. I think hopefully your friends like you. I think salary negotiation with friends is tough. Thankfully, we've always kind of had compensation bans, so we've been able to say this is what everyone else is going to be making. So we have to stay within this to make the conversation better.

That's smart.

And then just working with friends. It's all about being transparent, sharing candid feedback, setting expectations appropriately. I want to be friends with everyone at my company. This is one of the biggest reasons why I'm a founder, is actually this idea of building a good company. And to me, that means a company where everyone is actually viewing this job as the best job they ever have. And I actually get more fulfillment from that personally than becoming the biggest company in the world. I'd rather we have a company where everyone actually leaves their job loser day super energized and is going home and is excited about the work they're doing. And if we do our jobs right, hopefully we can make them generationally wealthy too, so that impacts their family and their kids and their grandkids. So that all starts with, like, making sure the team is really aligned with what we're doing and excited about it and keeping them engaged by giving them the opportunities for them to grow too.

Yeah, that's really cool. And are there any things that you would recommend if someone's hiring their first people in terms of just like, you know, like, making sure that people are energized when they leave the office or, you know.

Yeah, I think for us, like, I just really wanted to make sure everyone wanted to work here and I told them all the reasons why they shouldn't. I was really clear. Like, I was trying to convince people not to work at Browserbase. Like, I mean, obviously, I think the first half of the conversation is me selling Browserbase and why it's so great and what the upsides are. But at some point in the conversation, they also need to want you. I think as a founder, especially a solo founder, your first few hires, you're like, I need this person. If I don't get them, we're screwed. I can't move forward. That just results in people having not the right expectations aligned. So I always try and start with the sell of why you should work at browser base. This is like, here's the opportunity, here's the world we see. And then I end with, here's all the reasons you shouldn't. Like, hey, we sometimes work out of core hours. That's okay. It's expensive. That doesn't mean you have to be working at the office for those outside the core hours. But just know that it's going to happen or there's a lot of work here. It's going to be kind of hard and stressful. Sometimes there's fires, we're running around, we're reprioritizing. It's very dynamic. The more that I can lay that all out so they have that choice. I think it results in us having a higher comma, higher success rate. And for us, that's the most important thing is making sure people come and are successful in the role when they join.

Yeah, that's really cool. And what were you looking for in people that you were bringing in? Was there, like, stuff? Because I guess you worked with a lot of people within DevTools and you probably have, like, probably have some kind of mental stack rank.

My hit list.

I would want this.

Your top five. No, I didn't have any sort of CRM I actually liked. We hired someone who came inbound from us on Twitter, who saw one of our videos. I put out and said, this looks great. I'd love to work with you. Like, an awesome hire and a great signal. I mean, we hired from all different channels. Like, we had a recruiter for one person. I met somebody at a hackathon. We hired them, an old co worker of mine, people who came inbound. Like, we've really used like every channel we can to hire good people.

And is there some stuff that you like, you're like, oh, this. Like, you know, they. They do something, they say something, you're like. Or you see some sort of specific type of work and you're like, yes. Like, this is the kind of person that I'm.

I think I now have a pretty good nose for Eng talent. I cannot distill that down into why. It's pretty crazy. But I've hired a lot, like across like three, four companies now. It's. It's weird. Like, I actually can assess Eng talent pretty reliably in the first conversation without even seeing any code. Yeah, I think it. In the end, what I was looking for with browser base is I'd always ask this question, which is now ruined after this podcast, which is like, what, what's your favorite dev tool? And tell me about the tools and infrastructure that you love and why do you love it and what don't you like? And from that, it actually, it can be in a conversational setting where now I'm hearing about this person's product preferences, like what their expectations are of the things they work with and for working at an infrastructure company, you probably should have some opinions around infrastructure. Like, if someone says stripe is amazing, like, oh, yeah, I like stripe. I see that. And then they say usage based. Building a stripe is really poorly built. I'm like, okay, cool. They really know what they're talking about. But if they say the Amazon console is really the pinnacle of developer tools, it may be a red flag and you want to reconsider, you know.

So, yeah, it is what it is. Yeah, that's actually a really good point because I feel like this is. It's like there's this skill that doesn't kind of show up on like, resumes traditionally about like, you know, API design or like, like having something that just feels like. Feels good, you know, like when you use it, like using it, this API, it feels good. And some people are really good at kind of getting to that, whereas others, I feel like it's something that probably is quite difficult to kind of.

I have a crazy analogy here.

Yeah.

Okay, so buying a dev tool is like buying a jacket.

Interesting.

Okay, when's the last time you bought a jacket?

Yeah, I bought a jacket just before I came.

Okay.

I get a Patagonia one just to fit in.

Well. Okay, well, that's an easy buy. When you buy a jacket, maybe you see it at the store and you're like, okay, yeah, that's a jacket. It's got sleeves, it's got pockets. It looks nice. If you're buying linear, it's got gradients all over the place. But you still got to. Before you buy the jacket, you got to try it on. You know, you got to like, okay, the pockets are here, the sleeves feel right. It's cozy inside. I think it's the same way as like, buying a dev tool. Like, no matter how sexy the landing page is and like, has all the features, developers need to try the thing right before they buy it. And yeah, look at that jacket. Right. And for us, we actually try. And when you finish our signup flow, you're actually dumped in an IDE in the web browser where you can click run and you can see code being run on a browser. You can edit that code and play with it. You immediately see where browser base is used for and how it works within the first five seconds. And that allows us to move forward that try on, period. The moment of magic is what some people call it, as early in the signup flow as possible because we're building kind of complex and previously niche infrastructure. I don't think a lot of People know the in depth parts of the Chrome, DevTools protocol and Chromium or even Playwright. But when they see code runs here, browser does this, it kind of clicks. And that's like when I see that the session recordings of people doing that, I'm like, oh yeah, they get it because now they're typing in it and they are editing this thing live and now they know how they can build their thing using browserbase.

Yeah, that makes total sense. And I was speaking to Colin from Clerk and one of the things that he was talking about was like they want to get people not to use a sign up component. They found that like sign up and login component people weren't really like getting the value of clerk. They had to get further and add like the profile component. And then they would suddenly see like, oh, I get this gives you more than just like the, you know, the stuff that I had previously. Is it like, is that part of it? It's like you're trying to get people to do a specific thing once they log into browser base and if they do that, they're very likely to actually try that to use it properly.

Yeah, for us it's like, do they run the sample code? That's generally sample code. You have to use your terminal and git clone and then run this SDK or IDE or whatever. But our sample code is in the dashboard and it's a fully functioning ide. So if they run the sample code and they modify it, they're in, they get it, they understand how this works. And I think we're doing a pretty terrible job with this right now. I'd give us a C. Okay. But it's also been eight months.

It seems like that's better than almost every.

It's still working. Our conversion rates for post sign up to upgrade are above market and I'm happy about it. It's not the brightest burning fire, but it's one where I think you asked, how do we move so quickly? I do regret the quality of some of the things we have at browserbase. I think I look at our docs, I think they'd be way better. Our SDKs, I want to make our SDKs 10 times better. Maybe that's just every founder says that about their products. But being okay with quality for now, while you focus on more important things, we focus a lot on infrastructure scalability. Like in July, we actually just could not add more browsers. We had reached scaling limits that we didn't think we'd reached until the end of the year. So we had to kind of say we need to make sure this infra can go for the next hundred thousand concurrent browsers. We put all of our efforts on that and because of that, we're a small team, we haven't focused on things. So being a founder means constantly prioritizing different things. And for us, making sure it works great and works reliably was more important than making sure the docs are the top tier docs. Like, I want to move the proxy session section outside of the subsection and make it into the sidebar thing and like rewrite this whole thing. And rate limits need to be clearer. Like all that stuff just kind of sits in RAM in my brain and like, yeah, but that's okay because the team is going to keep chugging through all that stuff.

Yeah, I actually really agree with you and I feel like it's kind of. It's actually not necessarily like something that is like, I hear people say like, you know, the docs are like the most important thing and all sort of stuff. But like, when you look at OpenAI, they massively deprioritized kind of docs SDK and stuff, and people were still queuing out the door to use it just because it was so good, the core product. And I feel like that's kind of what you're describing is like, if someone is supposed to run a browser session for a very specific important thing and it doesn't work, that's going to cause them actually a lot more pain. They'll probably bear with you and just send a support message and if you reply to them, that docs thing is not an issue. But if, if things don't run reliably, it's like that is an issue for people to run their core business with you.

It's the most important thing is reliability of the infrastructure. And it's been our number one focus is making sure how many nines can we get and doing that from day one. And I think we can tolerate docs being a little bit. There's a grammatical mistake or something, but we can't tolerate the infra networking and that's been where we shift our priorities. And the reason why I'm saying all of this is I think a lot of founders don't talk about the things that they have to that they're not proud of. Yeah, exactly. And like, I've listened to some conversations that I'm like, oh, wow, these guys are crushing it all over the place on everything. Yeah. And like, I think you open it like Crossbase is Crushing it. Like as a hot company, like even a hot company has things that we want to improve and I think that's okay.

Yeah.

Like if you don't, as a founder, especially solo founder, if you don't accept that there are going to be fires burning.

Yeah.

You'll never actually do the most important work because you're going to run around like a chicken with your head.

Yeah.

So, yeah, for us, we focus on the most important thing, which is reliability. We work with great people to help us out when we can't have capacity. Shout out Charlie, who wrote all of our docs. I know. Hope you're watching. Like, you know it's not Charlie from. Yeah, Charlie from. Yeah, Defer favorite dev tool companies RIP so good. But yeah, like, I think that's where we work with other people to help kind of like move our product along when we can't focus on it. But in the end, every product has these little things you want to make better and as long as you know about them, then you're in a good place. But the worst thing is if we don't know what's bad about your own product, that's like the scariest thing because then you have no idea what you need to go fix.

Yeah, yeah, that makes total sense. And I think it's a really good point about knowing what you don't prioritize. And I, I, because I, I do try to ask this. It's just like it's some, a lot of people, you know, aren't necessarily in the habit of like talking publicly about like, oh, okay, these things, we're not so good. But it's always like, if you really, really care about, like there's probably a few things within every company that they really, really care about and they're really, really good at, hopefully the things they care about, but you can't. Yeah, it's really hard to like care about everything and focus on everything because at startups I feel like it is for better or worse, you can try and make people give them agency, but there's still so much that's like, if Paul doesn't care about it, then it's going to be really hard for you to be exceptional at that thing.

Yeah, I think self awareness is the first step before self improvement. So for us, if I know what I want to improve, then we can go improve that. But if you publicly say, yeah, everything is so great about our product and then someone looks at your docs and there's like this section that's unclear about burst versus sustained Rate limits. That's in your brain. I don't know. It just feels like the most important thing with infrastructure companies is that we're building trust. Our customers are trusting us with mission critical workflows and they have to believe us. And if you lie to your customers, they're not going to trust you. If you do that repeatedly, you'll lose customers. So I think we bias to being more authentic and transparent where possible, just so that they know that we have their. We're going to tell them when things aren't going to work. You don't want to promise something that you can't deliver on and then somebody else is going to be screwed over by that.

That's really cool. No, that makes complete sense.

It should be the default. I think it makes sense because it's like, oh, cool. Being honest with your customers. That sounds like a good idea. But I think there's a lot of startup knowledge which has been like sell first, build later. And yes, there is some of that you should do. But I think oftentimes if you sell the moon and you can't deliver on it, I think it just burns a.

Lot of credibility because that is a good point as well. There is often this talk about, especially on Twitter and stuff right now there's a lot of talk about scale and how you don't actually need to worry about this stuff.

Oh, the VPs levels, IO stuff.

It's kind of like. So it seems like there is some kind of nuance there of when you should and shouldn't care about scalability. For instance.

Yeah, I think if you can run your whole app on a VPS and it works great all the time, you should do that. I fully believe that if you want to run your own browsers, I support that and I'll tell you exactly how we do ours. But my bet, and the reason why I build this business is that it's actually really annoying to do that. I've done it myself. I wouldn't have started this company if I didn't think we had sufficient zero to one maintenance pain. It's hard to get started to run, let's say 1,000 concurrent web browsers in a cloud environment in a secure way. That's hard to do. 0 to 1000 concurrent browsers. But then it's also hard to maintain that fleet of browsers and deal with things like Chrome updates that are very important for security reasons. You have to roll the whole fleet or do you want to support file downloads, which means that you have to synchronize each Browser's download folder to some S3 bucket and then map that for your downstream customers to download and then you just like it's a death by a thousand cuts on improving that thing.

So you become a full time job for a small startup.

Yeah, sure. Just run your own postgres. Oh, but you want a nice ui.

Okay.

You got to go buy Plastico and then oh wait, you want to do replica. Okay, you got to figure that out. You want backups or just use Super Base? I choose to use Supabase and I like that.

Yeah, the very cool guys.

Very cool guys. Yeah, the other Paul.

Yeah, the other Paul Dev tools.

Paul's.

We've got Paul from.

Jam Socket.

Paul Butler. Yeah. Who's also a browser guy. Yeah.

There'S a Paul army building here. Watch out. Maybe that's why we have VC Marketplace. Paul devtool founders is the moon.

Wait a second.

Yeah. If you rename change your name to Paul, you're in the group chat now, so watch out.

Yeah, that's incredible. So this is like the second time round that you're going on like building a devtool. Are there things that you're doing differently this time consciously that we haven't covered so far?

Yeah, I mean solo founder is one of them. I think. I love my co founders. One of my co founders actually became a customer today, which is pretty cool. Yeah, awesome shout out lan. But I think being a solo founder allows us to move with a lot more speed because there's no alignment needed. When you have a co founder it's like you and your co founder getting aligned and then the founders with the team being aligned. When it's just me, it's just one step, remove. And I think being aligned is the most important thing for a startup and we can make that a lot faster with just me. I also think that we're working fully in person all the time.

Yeah.

Five days a week in San Francisco. We just got a new office and that's been great. I mean it's so hard because I meet so many amazing devs that I want to hire that I can't because they don't want to move from where they're at and I totally respect that. I don't think one is better than the other.

Yeah.

Like I think what Jake is doing at Railway fully remote is like really impressive and the way they pull it off, I think it's like so cool and they do a really good job of it. So it's not like a choice of what's better or worse. But, like, we all opted into this culture of being in person and going to the office every single day, and we need to honor that because as soon as we break that, then it's like, well, why did we all agree to this in the first place? We're building an in person company and that's been like a very, like, conscious and sometimes painful decision.

Yeah.

You know?

Yeah. Yeah. What would you say, like, the biggest benefits of being in person?

Yeah, it's. It's hard to put it into words, but I think, like, there's this more contagious energy. You get to see a lot more of, like, when someone is like, really struggling and, like, they're putting in a lot of work into something and it's really hard. So I think it makes the celebrations of big achievements much grander.

Yeah.

Because you, like. I think when someone is remote, at least for me, it's harder to gauge the effort they put into something.

Yeah.

When I know Dom is at the office, like putting in a ton of work on this new browser pooling feature and it ships, I'm like, that's so awesome. Like, I know hard you worked on that. And I literally saw you there before I got there and after I left, like, for weeks straight, you know, so it feels like everything becomes a lot more tangible with the work that's being put in. And it's just fun. Like, we go out to lunch and dinner all the time. Like, we hang out. Like, it makes it really easy to have impromptu things happen.

Yeah.

Which is a lot harder when you're remote.

Yeah. I was actually talking to someone who was working in your office and I was like, oh, what's the name of the place that you're working at for?

Solaris.

Solaris. Yeah. Yeah. And he was. I was like, oh, do you know Paul? And he was like, yeah, yeah. It was funny because there was like, there was just Paul in the office and then there were like, more. And then they were like, even more. And suddenly there were like all these people in this, like, little office. And now they've got. I think.

Yeah. We've had like three or four offices. I remember I got the first one, it was just me and three desks. I was like, this is so much space.

Yeah.

And then we have five people and three desks. And then we got a bigger office. And then we've run out of desks way too often. Actually, even in our current office, at our current hiring plan, we'll run out of desks in the next couple months. So I'm going to give up my desk probably in November, and then I'll work from a couch or something.

Has it been harder to scale desks or browser sessions?

Ooh, it's easier. I mean, I don't know. It depends on if you're in US West 2 or not. I think it's been easier to scale browser sessions than desks these days. It's harder to get more desks, for sure.

Exactly. Wow, that's actually crazy. Okay, Paul, I think that was like, pretty much all we had time for. Is there anything else that you wanted to talk about before?

No, I was just going to add that it's really great to have this podcast and I think that it is a small community of infrastructure builders and dev tools builders. And the more that we can kind of get together and share the pros and cons and the pains and the stuff we're going through, I actually think that it makes the whole infra community much better. So I'm happy for you to put it together. I appreciate it.

Yeah, no, thank you. And it's so cool to actually, like, I think this is, yeah. One of the very few dev tools that I've seen, like, at the earliest stages going like. And it's been so cool. So I've learned a ton from you just like watching how you do things and stuff. So it's really cool to like actually have time to ask you the questions that I had. So, yeah. Thank you very much.

Thanks, man. Good to be here.

Yeah. Expecting a huge IPO in a few years and that you'll be back on.

We'll do a 10 year reunion. I'll have no hair.

I've already got no hair.

There we go. Perfect. I'll grow a beard again. It'll be a good one. Yeah, dude, that was fun.

Thank you.