Paul Klein IV: How to Build Browsers for AI Agents

Welcome to the Contagious Code Podcast where we dive deep into code, learn practical skills, celebrate the beauty of engineering and eliminate imposter syndrome. I am Tejas Kumar and I've been building on the web for over 20 years at places like Vercel, Spotify, Zeta and more. Today my guest is Paul Klein iv. Paul is the founder of Browserbase. Browserbase creates infrastructure for browsers for AI agents. The web is used by humans, you, me and everybody. And we use the Internet today. But with the advent of AI and large language models that can call functions, Browser Base helps create a web that's usable for AI agents. And how they do this is by starting with creating reliable infrastructure. Now, if you wanted to provision, build and scale a fleet of browsers that work reliably every time, that is monitorable and reproducible, then this is a huge effort. And Browserbase does that so that you can focus on creating agents that interact with the web. That's their initial offering. We also talk about an open source offering they create called Stagehand. In this episode we go into technical detail, a lot of technical detail about how they're building this platform, what technical challenges they've faced, we've talked about decisions around going from Postgres to Clickhouse and more in terms of technical detail there. We also talk about the business side and product market fit. And this is an exclusive in the podcast world where we go into detail about Browserbase's newly announced Series A. They just recently as of last week announced their Series A round co led by Kleiner Perkins, an early investor in Netscape, which was arguably the web for humans and now browser based, which is the web or the usable browsing experience for AI agents, co led by Kleiner Perkins and CRV with participation from Okta Ventures as well.

This is really cool.

We love celebrating business, but also technology. And this episode combines both.

All that to say, if you're interested.

In what it takes to provision, scale and monitor reliably, something like Headless Clone or Playwright, excuse me, for AI agents, then this episode is for you. If you're interested in AI agents themselves and what AI engineers are and all the AI stuff, this episode is also for you. Or if you're an entrepreneur, maybe thinking of starting your own startup, considering product market fit, fundraising and Series A, this episode is also for you. This is one of my favorite episodes because it really, in my mind at least balances very well technical and business sides of the industry.

I'd like to offer this to all.

Of you at no cost, but the way we can do that is through sponsors and partners. Because this is very much separate to my day job. Let's take a moment to thank them. The Contagious Code Podcast is partnered with codecrafters. Codecrafters teaches you how to code like I do. My most popular talk ever was one where we just didn't import React, but we wrote some React code and then when we got errors, can't read create element of undefined, we just like wrote React from scratch. And that's how codecrafters teaches you. So they have you pick a programming language so JavaScript, Python, whatever, and a tool for Git, Redis, Docker, whatever. And then they have you build that tool from scratch in the language you chose. And by doing that, you get better at the language and better at the tool because you build it from scratch and you understand its underlying mechanism. They have a generous free offering, but if you want to pay, you can get 40% off if you follow the link in the show notes. That's tej as codecrafters. The Contagious Code Podcast is also partnered with React Africa, an upcoming conference where I have the privilege to deliver the opening keynote in Casablanca, Morocco. There's a link in the show notes as well. And if you want to win a free ticket to the conference, share your favorite moment from this episode on social media and you'll enter a raffle to do so. Thanks so much for sticking around. Now for my discussion with Paul.

Paul Klein. Welcome.

Hey man. Good to be here. Thanks for having me.

I'm so excited to talk about Browser Base. I saw this ad on X, formerly known as Twitter, where it was so compelling. It was actually one of the better tech ads I've seen in a long time, which is they promised us robots and we got roombas and it turns out AI is not very useful. And it's just such a great ad. For those who seen it, we'll put a link in the show notes. But all that to say, I've been a fan of Browser Base for a while and I'm super honored that you'll be here today. I can't wait to dive into all of it.

Yeah, I'm excited to talk about it. It's rare that we get to kind of talk about companies being started at this new generational wave of AI and infrastructure. And it feels like everything's kind of changing right now. So we just got a lot, we got a lot to talk about. So it's going to be a busy, busy show.

Yeah. Maybe we can start by laying the basis for discussion Simon Sidnek often says start with why. So let's maybe start there. Why browser base? I think I already alluded to it with the roombas and robots. But in your own words, why browser base?

Yeah, I started browser based, really based around how software is going to change in future. Right now, software makes us faster at what we do. You can create a podcast faster, you can write code faster, but it doesn't often do the work for us. The future of software is software doing the work for us, and that's where browseways comes in. You know, we do work on websites using web applications, and often via a web browser. So if the future of software is software doing the work for us, I mean, software is going to have to use a web browser, just like you and I do. And browserbase is a programmable web browser designed for AI applications that are going to do work for us. So browser base is really powering a lot of the future of software, this kind of primitive web browser infrastructure.

There's some who hear that, who might be somewhat startled by this idea that software does the work for us. Because I feel like the question on people's minds at that point is, okay, but then what work do we do? Do we become redundant? Do the machines take over? That's the doomer view. Right. But the other side is, oh, this is great. This frees us up to be artists and thinkers. Maybe we'll go back to actually thinking instead of like mindlessly scrolling TikTok. I'm curious what your take on this is.

Yeah, I see us evolving to be overseers and facilitators, you know, and more. We know that, like, the current state of AI is that like, things like planning steps or understanding how to tie multiple things together is still not that good. So I don't see this as being any sort of like existential threat in the short term to humanity, where I see this as just like the next logical step for a more productive people. And yeah, I hope that we can help power that in a way that's actually good. I think that the rules of the Internet are going to change very soon too. Like, how do bots navigate the web? How are we okay with that? I think we have to think really deeply around how computers use the web just like people do. And there's a lot of interesting implications there to think about.

Yeah, some people see the future of the Internet. There was a guest on the podcast, the name is escaping me right now, but somebody once said, gosh, I hope I remember they said that the future of The Internet is actually that 90th percentile of bots tend to make up most of the users and humans not. So humans interact with their own maybe personal bot that then goes and uses the Internet and comes back. And that's because the Internet is so uninhabitable for human beings. They were making this claim that, you know, if you go to any website there's paywalls, there's cookie banners, especially in Europe, there's all these pop ups and then there's a lot of spyware and trying to sell you things that you maybe don't want. It's really almost hostile for humans.

Right.

And so they were saying maybe in the future we won't even use the Internet and just be like a bot sort of playground. Do you think there's some truth to that?

I think that like the longest view, like we may even not use most software, right. We just are going to be talking to like our device or our neuralink will trigger my spreadsheet to work. Crazy. But probably more pragmatic in the short term. You know, we're going to be existing alongside people who are just getting access to the Internet. You know, our agents are going to be out there, you know, using the websites that we do because there's still people who have to use those websites. It's kind of like how it took a while for email to really take over. Vaccine is still a thing. For that reason. I'm, I'm like hyper pragmatic. It's actually probably a problem. I'm not really a big visionary founder person because I just think that things move a lot slower than we'll give them credit for. And with regards to this, like it seems like people will still be using the Internet alongside, you know, more advanced pieces of software that maybe go out and actually kind of pull your insurance information from the insurance website as opposed to you having to log in, download the statement and upload it somewhere else. That's what I just want to remove like all this software to software gaps.

Yeah, I really like that. And I like that you say, and I'm quoting you, that things tend to move slower than we give them credit for because up until I was an adult, fax was still very, very common. And like you said, some people still use it today. And I think email and even the Internet could probably go that way, meaning we have at least two generations, two generations out. I think one thing that may be important for this insurance case you bring up is there has to be some authentication layer, right? Some safe on device Way to say here's my login details for the insurance company, now go get my stuff. And I guess that's where a lot of the innovation needs to happen, at least from my perspective. Like, I don't know that we have a way to make digital identity for an agent so accessible, but maybe we're getting off topic here, but I'd love to get your thoughts on that.

It's an important thing to talk about. I mean, this is where we can get technical, right? So my background is I actually used to work on the login and identity team at Twilio. I actually built Twilio's login page. So I know a lot about, you know, like I ran RXSO products. Like, you know, talk to me about saml, SCIM or sso. I'll go deep on it with you. And we already have a lot of, you know, frameworks and protocols for delegated authentication or authentication with a different identity provider. There's a lot of interesting stuff out there that we can pull from. I was jamming with Colin at Clerk, he's one of our investors and Clerk is an authentication company about what does it look like for an agent to like oauth into your account? Like maybe.

Exactly.

It gets access, it's granted some sort of scope of access where it's maybe it's read only connects these things and maybe you have to approve it on your phone. Right. Those primitives don't exist yet. But Browserbase, we try and partner with all the authentication providers out there to make sure that we're gonna be able to help them and guide that. But even like in lack of all of that, we often see that cookie sharing is the accepted practice here. And what is a cookie but you know, basically a time limited, it has an expiration date, it has some sort of scope, it's. You're acting on behalf of the user and it doesn't have the username and password so you can share that around. It's not the best. There's a lot of drawbacks to sharing cookies, but that's kind of what we have right now. And it's okay for some use cases, you know, but the goal is that we have something better. And once again, it's just going to take time and yeah, I'm excited to see what innovations happen on the other.

Side, time and specification and so on. Awesome, thank you for that. We've spoken quite a bit about why Browser base. Now let's for the listeners and for the basis of discussion, talk about what browser base is I can say to you what I think it is and then you can tell me where I'm wrong. This is what I do with most guests. It is a way to have an LLM operate a browser. Actually, it sounds wrong to me. I'm not going to go with that. What I've heard it sold to me as is probably wrong. But I would love you to take all of this and make it right. Is like Puppeteer or what's the Playwright? Headless Chrome, but in the cloud that LLMs can use. How far off reality is that? And then what actually is browser based?

I nailed it. You know, I think some of that's aspirational. Right? You know, we want it to be. Browserbase should be the tool that LLMs use when they want to go browse the Internet. That's our goal now, that is in practice right now is that we are managed web browser infrastructure. That means that we run a fleet of browsers that our customers connect to using browser automation frameworks Puppeteer, Playwright and Selenium. And the gap between those two things is that while LLMs can generate playwright code and our customers are often generating the right code, but they're not controlling the browser necessarily. It's a high level, natural language level. You can really think about browser based from a technical standpoint. And I want to be technical because that's the best part of this podcast. We manage this complex, stateful distributed system of running many web browsers in a cloud environment that comes with a lot of pain. You can look at this as a CDP API. CDP means Chrome DevTools protocol and puppeteer, Playwright and Selenium, they talk to a browser using the Chrome DevTools protocol. That's why they're interoperable. There's an asterisk there. Selenium uses this thing called webdriver, but it's CDP compatible with this workaround. But to kind of get out of the weeds for a second, you know, just running those frameworks in production has a ton of pain. And maybe I can walk you through a story of what our customer experience is when they try and run process. Does that sound okay?

Let's do it. Yeah, let's do it.

So I'm Paul, the programmer, and I want to automate this insurance website. Okay. I go look at these frameworks. I use Playwright, built by Microsoft. It's the most popular and it's the newest one. And I start writing my code. I write it by hand. Let's just imagine that I want to hard code this thing. So I automate this insurance website, I log in, I get my document, I download it and now I'm like great, this works amazing on my local computer. Let's go deploy the product. Can't be hard, right? Okay, so we want to deploy my Playwright code to prod. I would probably go with a Lambda or maybe like a Vercel serverless function or cloud worker. And I start going on this Lambda path and all of a sudden I hit a roadblock. I can't install Playwright on this Lambda because the Chrome binary, you know Chromium, the one that we use on our computers, it's quite large, it's over 250 megabytes in size. And that's over the Lambda file limits by default. So I have to use like a Lambda layer. I figure out how to get it on there. I use like a different version of Chromium, maybe a lighter version. Now I have Chromium on my Lambda, but it's running extremely slow. And you realize that Lambdas actually can only run a single process at a time in Chrome with multiple tabs runs multiple processes. So you realize that Lambda is not strong enough to run Chromium. Remember Chrome on our laptops is pretty powerful. It's the most heavily CPU used app on my laptop right now. So you go turn to, well I'll use EC2, I'll go to beef here machine. And now all of a sudden you're running chrome on this EC2 instance. But you gotta manage state if you want to run multiple of these browsers. Like how am I connecting to the right one? Well, I need like an ALB that's proxying my websockets through and websocket routing becomes kind of a pain. And you're all of a sudden you have a full blown kubernetes setup to run your browser in prod in a way that's reliable. And then you finally get your browsers running, you finally run your Playwright script, you connect to the browser and you get blocked. You go to your insurance website and they're like, this is an Amazon ip, no you should not pass. So you got to go by proxies from some gray market residential proxy vendor. You have to go buy a captcha solver from like a discord. And you're like what am I doing? It's like feels like a drug deal just to get this thing to run on the web. And that's kind of that whole infra problem is what people have to do to run headless browsers in production on their own. And that's what browseway solves. You know, instead of doing that, you can just point your playwright out our browsers and we'll run basically you can start in like a few minutes.

And it looks like humans, meaning I'm not going to get this like cloudflare verifier human capture thing because it's recognizes an Amazon ip.

Yeah, well, it doesn't look like humans, it just doesn't look like an Amazon server, you know. So we just do the best practices to mix up our fingerprints. Like we want the browsers to look differently because our customers are using, you know, their different use cases. They should all look different from each other. Right. We also provide proxy so it doesn't come straight from an Amazon ip and we think that you can go through different ip, that's going to be fine on the reputation side. So we do a lot of like, I would say that we do the best practices, but we're not like this sneaker bot team, you know, like if you want to buy the latest Jordans using browser based, it's probably the wrong piece of software. We're not perfect.

Yeah.

We strive to just provide you the best practices, but also the best infrastructure to reliably automate the web. That's our goal.

This is so great and thank you for that case study that really captures the pain that I believe most listeners and I have have dealt with. Here's one case study of that for me where I so at some point I was running a business and I needed to take care of all of my taxes, expenses and things. And I took, I think in a month like 52 Ubers, right. And there was no way in hell I was going to click through each webpage in Uber, download the invoice for each trip. As far as I know, their API didn't also have like bulk export for all your invoices. And so I was like, okay, this is going to be a puppeteer, this is going to be a playwright thing. Only to find out that somehow they detected it wasn't an Amazon ip, but it was the browser. The browser was not a human browser. Just somehow knew that and didn't help me automate that very well. And so then I had to, like you said, speak Chrome DevTools protocol, I believe.

What is it called?

CDP.

Yeah, CDP. The Chrome DevTools protocol.

Yeah, exactly. Had to speak that and then like inject my cookie or have it use the browser that already had my cookie. And it was just a whole bunch of hoops to jump through. And as you Mentioned before you know it, you're running some weird like Frankenstein kubernetes and it may not even be Frankenstein, it may just be good, but it's, it just fights you at every single layer.

It's overkill for your thing you want to build, right? Yeah.

Right, yeah. And then if you're a business, it's maybe overkill of your like time and money.

Right.

Because people work on this and they have to iterate and time to market can be massively affected. So I definitely feel a pain and I'm happy that browser. So what it sounds like is browser base, if we speak like developer, is really just infrastructure to reliably run browser based workflows and then have Gen AI LLMs leverage those workflows.

Yeah, well I talked about the infrastructure here and that's browser based product. But what's really exciting is what we plan to build more of, just also a better SDK for automating the web. So we see all of our customers using large language models to generate this browser control code, Puppeteer, Playwright, Selenium, based on some prompts, some agent agent steps, et cetera. We want to not only help with the infrastructure, but we're releasing this open source SDK called Stagehand, which sits on top of Puppeteer, Playwright and Selenium and takes natural language and generates the underlying browser control code. And that's an open source framework we're going to release to the world because we just see everyone doing a similar workflow and we know that we can deliver more value on our infrastructure if we help more people build these browser nations. So the goal is not just to be the infrastructure but also the default framework, really the tool that people choose when they need to automate the web reliably.

So how does that work? Does this tool Stagehand, it probably requires an API key from some LLM vendor, OpenAI, anthropic, whatever. And you set it up with some type of configuration and then what? You give it a prompt, like if I think of a contrived example, maybe find the best reviewed movies across the Internet and then it generates like a playwright script to go to, I don't know, IMDb, Rotten Tomatoes, and then it runs that script on browser base. Is that close to how I can expect it to work.

It's not going to order you a pizza, you know, it's here to help you reliably automate the web. So it's a little lower level. We know that step planning is a huge pain point for large language models. Right now, taking this high level thing ordering pizza and breaking it down into steps. With Stagehand, we're kind of meeting LLMs where they are right now. Its goal is actually to help you, like, atomically automate each step. So maybe it's like, right, given. Let's say you could go to Amazon.com, target.com or walmart.com three different websites, but you want to build a workflow to buy popcorn. You know, search for popcorn, click the first item, check the price, make sure it's under $20, add to cart and purchase. Those are four steps that actually build up a generic workflow that you could run on multiple different websites. Right. So Stagehand is really designed to help developers build these generic workflows that we see a lot of our customers try and do, because for the first time ever, it's actually possible to generically automate workflows across many different websites. And Stagehand is that tool to help with that. And it's great for our business because it helps people build things they couldn't have built before. Now you don't have to build this additional layer of CodeGen to get started on Browsera. Really realize the vision of what you are trying to build as a customer.

Yeah. Is that available to use and try today?

Yes, as of the time this podcast comes out, it is available and you should try today.

Good.

Which is good.

I really want to. Yeah, that sounds great. You know, a lot of my podcast here is run by AI agents. I do almost like I show up and record with you, but honestly, everything else is just automated away and so that gets very expensive and breaks quite often because it's just me hacking. I'd love to see if Stagehand can help make those steps more reliable. So I can't wait to give it a try. Great.

Okay, so we have like an email. Sorry to belabor it, but we have an email that it plays wordle every day internally. And it's kind of fun because it's like wordle is a web application. You know, it's making guesses. And it's interesting because, like, wordle is actually quite hard. You know, like, I. I lose at wordle sometimes. And it's fun to see our AI agents wake up, play wordle and post the results in Slack and see how it does. So it's really interesting to see what people can build with this thing. And I'm excited to launch it, especially as open source, because that's really how you can kind of get back to a community and let people really hack and build on stuff.

Well, yeah, and then when they want to deploy it, they come to your product. Right.

But they don't have to, you know, they can take it somewhere else. Yeah, sorry.

How often does your bot win wordle? Is it like 100% win rate? Does it fail sometimes?

I think it's like a 65% win rate. It's hard. Wordle's actually quite hard for LLMs to win, as far as we understand it, because there's this idea of understanding the previous words and putting together. There's also not a lot of training data out there for win wordle. So it's just a fun test for us, but I don't think it's going to be the best wordle bot you ever built.

That's so awesome.

I would love to see this. Instead of posting to your slack, just post to Twitter every day. That's like free marketing for browser base.

That's a great idea. Watch out. Can I do that?

I support that. That's so I retweeted once in a while. That is just to see this, like this, this, this quote unquote living machine just wake up and do a job every day. So cool. All right. We mentioned the word agents multiple times and this is one of those words, Paul. This is one of those words that is ubiquitous. It's everywhere. And it doesn't, at this point in time, at least as far as I know, doesn't have a, like a single source of truth definition. And people use this word to mean many things. I was at a conference some time ago where it was in the uk, where somebody was talking about how they built these agents in their organization. And what they had was custom GPTs, a feature of OpenAI's ChatGPT. It's a custom GPT where you can add documents to its knowledge base. And it effectively just does rag on these. But they were using the term agent and I was like, that's not an agent. It can't do reflection, it can't do tool calling. It can't work in collaboration with other LLMs. For example, how do you define agents? Just so that we get the listeners and ourselves on the same page.

I hate the word agents too. It's so messy now because I think everyone's grouped it together. The definition I really like, I think Chun Wang Zwicks is the one who put me on this is software that can autonomously choose tools. So software that's able to kind of say, this is the right tool for the job. I want to use this tool or this tool that. That to me Is Agentix software. You maybe give it some instruction and it's choosing the right tools to accomplish its goal. It has agency because it can pick the tools, but it's, it's still software. I think sometimes people kind of, what's that word? Anthropomorphize the agents where they're like people. This is your CEO agent. I don't really like that structure as much. I just think of software that knows how to choose tools as opposed to the software that we're used to building, which is where we tell it what tools to use. Call this API, download this file, extract this zip. So that's quite powerful. And that kind of aligns with that feature thesis I have that software has been doing work for us. If software is doing work for us, it should be able to choose the tools it needs to use to accomplish that job.

Right?

Right. Okay. So it's mostly centered around tool calling. I like that. I think that's close enough to my working understanding as well. About browser base, how does it handle browser sessions? Meaning you generate a script to log like the Amazon script you just had with these steps. One of the steps is add to cart. But often if I'm not logged in, it doesn't know which cart, like whose cart am I adding to. So then login authentication would be a step. How would that play out in a machine generated script, a playwright script that then runs on browser base?

Yeah, you're already using the lingo for browser base are primitive. So a browser session is one session from start to finish where you're running a browser. It's connected to websites, it's messing with your cache, your cookies. At the end of this browser session you can choose to persist the browser context, which is this directory that has your cookies, the network cache, your filled in forms, where does that persist to? We persist that on browserbase's side. So we encrypt it, put it up in storage and then if you want to use that context in future sessions, you can specify and say, hey, let's reuse this context id 12345 on my next browser session. So this gives you idea of similar how when I close my Chrome and reopen it, it knows where I visited, what pages I had, it knows, you know, where I've logged in and what my cookies are. It allows you to kind of carry that with you. And that's an opt in feature. We don't persist that by default, but for some customers, what they like to do is allow customers to log in, you know, in the first session and then they persist that then they reuse that across multiple sessions to kind of continue the automation without having them to log in every single time.

That's so cool. And these sessions are end to end. Encrypted.

Everything is over HTTPs, so it is encrypted in transit. The contexts are decrypted on the browser so that we can actually. They need to be used to browse the web but then encrypted at rest. So they're stored. Encrypted.

The keys to decrypt them are those.

How do those.

Are they generated on the fly and nobody knows them or.

Yeah, they're generated using your API key and assault, I believe.

Nice.

I didn't build the encryption part. This is the one part of the stack I'm not super well versed in.

But good.

We are soft to compliant and we've been audited quite a bit on the security side. So I feel pretty good about that. I'd have to go get the actual white paper account.

That's fine. 1. I think it's good that you're not the best informed on this and you haven't rolled your own. It sounds like. Especially because you're SOC to compliant. Because look, I live in Europe and this is. This would set up all the red flags of the German regulators. Right. They're like, oh my gosh. What you just persist my user data somewhere and I don't know about it. And so I think it's worth at least the question. This is. Sorry, go ahead.

No, I'm saying definitely. And I would add that it is the responsibility of our customers to really ensure that their users are opting in to this kind of data storage with browser base. Excuse me one second. With browserbase. Well, our goals.

You've just muted yourself.

I just muted because I was coughing. So back to what I was saying. With browserbase, our goal is to be an arbiter of good bots on the web. We want to be able to make sure that our customers are behaving well, that they're doing things ethically and they're being good web citizens. So we have zero tolerance for people who are harvesting user credentials who are like ticket scalping, who are trying to buy sneakers or hoard restaurant reservations. Our goal is that longer term we're going to be doing KYC on these customers to make sure they're using the web in a way that's a net positive for humanity and we'll take on that risk. It's kind of similar to how Twilio recently has had to do a lot with kycing customers usage of phones because all of a sudden we had all these spam test calls. I want us to get ahead of that. And it starts with us making sure we understand what all of our customers do. And I pride myself that like for every customer that signs up and uses browser space meaningfully, I do a lot of legwork to make sure I know what's going on. And I plan for us to continue to do that as the company scales. Because the way that browser could fail is if we chase the high volume but low value use cases. We chase the things that are unethical. If we let greed get to us as opposed to trying to be this primitive that powers infrastructure feature, I think that we will be in a really bad position. So for us we actually have to be really thoughtful about who are the customers who support how do we build features to make sure we're actually supporting customers, building the right stuff that's actually beneficial for people and how do we make sure we make it extremely painful to use browser for the wrong reasons. So we take a lot of thought in that recently on our product direction and so far we haven't seen any major issues there. And I'm going to knock on some wood so we won't see any in the future too.

That's good to hear. You mentioned KYC this term. Just to clarify, that means know your customer, right?

Right. Exactly right.

Okay, good. Just people get touchy with acronyms on this podcast. They go like he didn't explain what it meant. Great. Okay. So you can have multiple. This is so cool. So you can act as one or many users on a daily basis. What I'm hearing is I could use browser base and listeners could use browser base for example, if I wanted to be like a. And this may be nefarious. Maybe not. I don't know, you can tell me. But I could establish like some type of LinkedIn thought leadership by having like an LLM generate a very strong, very opinionated almost like. Or maybe just an educational blurb of text and then post it as me to LinkedIn every day at 9am I could automate that on browser base and have it run if I wanted to. Is that close to what some people might.

You could. You would be breaking LinkedIn service to service. So you may want to do that at your own risk, but definitely possible. And we do have people who are doing some LinkedIn automation. Once again, this comes back to like how are we complying with the software that we use to make sure that we're aligning with interests. Like, I think if you're providing value to the LinkedIn community, I don't think LinkedIn will get on your case too much about that. But if you're spam messaging everybody in your network, trying to get them to download the latest episode, you might get a little bit of hot water. So in the end, it's all about the spirit of the goals here. And the context thing is nice because you can persist your session across multiple browsers without having to do a bunch of jumping through hoops along at every time and do two fa, et cetera.

The really awesome thing I pick on LinkedIn, by the way, because it looks like people are already doing this on LinkedIn. If you go on LinkedIn and read posts, usually the thought leaders just have the same format. It's like an emoji bullet list of random things that sound cohesive. In any case. Okay, I'm asking these things because I understand now the value I can create and add with browserbase. One question about context and storing these sessions, are they portable? Meaning since it's a developer tool, can I choose Viya configuration or some other mechanism to say, hey, all my sessions, instead of saving them to browserbase Aside, here's my S3 bucket. Put them there.

Yeah, we have a self hosted version of browserbase. So if you want to deploy in your own cloud, you can actually do that. And, and some customers opt to do that for heightened security reasons. Maybe they actually want to automate some sort of intranet application. Maybe they have an internal tool. This is more popular for like very large organizations where they have, you know, some old thing written, maybe like COBOL or something. Right. That they're not going to rewrite what they need to like automate on top of. So their customers get their internal customers, their employees can use it and that's where like a self hosted prospect makes sense. Or if you really want to make sure you have full chain custody of customer data and you need to deploy it in your cloud. So it really depends on your use case. Like for stuff that's like more HIPAA oriented, we'd recommend doing a self hosted version of Browser base just because we want you to have complete control customer healthcare information. But yeah, in, in the end it really, you can't really slice and dice that. You know, it's either you go full self hosted or it's full browser based. We don't have to worry. You can kind of dump stuff on your own. That's just because we want to make sure we have full understanding of the security implications of that too. And sending out your data over the open Internet just seems a little insecure.

Yeah, that's fair. Could I build Perplexity with browser based portions of this?

Yeah, definitely. Web crawling vector databases for all the web data. If you don't want to ask questions, it will kind of do some brag against your vector datas of web data. I think Perplexity is an amazing company. We were both in AI Grant, which is Nat Freeman and Daniel Grosso's accelerator and it's been really cool to see what they've been doing with just building better search for people. And that's a piece of software that does work for you, kind of like back to that original point of making. So we'd love to power them one day. We don't currently but Arvind, if you're listening, hit me up.

Yeah, I honestly don't use Google anymore at all for anything. I use Perplexity. It's replaced all my searches. The last time I remember using Google was for something deeply personal that I didn't think Perplexity would treat with as much respect as Google, which is absolutely bananas just coming out of my mouth because we all know Google also struggles in that way and really I should maybe use DuckDuckGo or something in any case. Yeah, that's so cool. So through these questions Paul, what me and the listeners are getting at is a solid understanding of not only what browser base is, but how it can, how it's built. Also talking about encryption and so on, but how it, what we can build with it. And to that end what are some things that customers you recently crossed a million new browser sessions a week which means heavy usage, which. Congratulations by the way. That's awesome.

Thank you.

And it almost sounds like product market fit with this much usage. We can talk about that maybe separately, but what are, what are people building on browser based. That's, that's sort of making you go wow.

Yeah, I mean since then we've had just a tremendous growth in usage. You know, we've done much more than 1 million browser sessions per week and we've, we've run out of capacity in Amazon regions before. We've actually tapped out Compute. Yeah, we've, we are at the maximum size database that you're allowed to handle and I've had to move from a postgres to a clickhouse type of a database. So we're really facing real scale problems and the engineering challenges have been extremely difficult. This doesn't answer your question. But it's an interesting point. I think there's so many great dev tool businesses to be built on top of distributed stateful systems. Like if you find a distributed stateful system out in the wild, that is an infrastructure company that is open to be built because it is such a pain to run these things. You are scaling things horizontally, you're scaling parts vertically. There are bottlenecks, there are connection layers, there is, you know, management of state at scale in a way where you can't have things kind of clashed with transactional interactions. It's the most challenging type of distributed system. And yeah, we've had a lot of interesting engineering challenges we have to overcome to kind of solve this thing. Happy to answer the question. Around customer use cases, there's been quite a few. You know, I think that there's five categories of customers that we see. One is traditional web scraping. They want to just load a website, get the content back. 2 is also testing, maybe they're running some tests on their own websites. They, they don't really want to like run cypress in a GitHub action. They need something a little more robust. They want the session recording feature that we have which will show you exactly what the browser sees. And then these last three are actually the kind of automation ones which is, you know, AI agents, B2B software, professional services. So I'll go in reverse order. What does professional services mean? Professional services are these kind of newer companies that are taking software and replacing, you know, human experts with software and AI. So yikes, this is like the Harvey AI of the world. So Pilot, which does accounting software, right? They traditionally you have accountants or lawyers or integration attorneys. In the case of Lighthouse, one of our customers and you know, instead of having that person go onto these websites and automate something, you can have browser based and the software you build actually go out and help augment the role of these professionals that you're often paying in some sort of hourly capacity. That's professional services, B2B software. There's just a variety of like software needs that are helping automate processes and these often are things that you outsource to professionals. This is something they can maybe do in house, like customer kyc. We talked about KYC for Browserbase. Well, there are startups that are doing KYC with browserbase as part of the solution where a customer signs up for your enterprise product. You need to go understand, what does this customer do? Are they a registered business? Do they, Is their business address real? Where are they located and is that a legitimate promise that we can serve. And that often requires going out to the web and doing much research. So these kind of B2B software categories is really just a lot of stuff. We have B2B go to market, use cases, B2B procurement, where maybe you have some sort of item and you want to see where you can buy it from with the best price. Oh, okay, now I got to go to 10 different vendors and type in this item and find it, maybe even see how long it's going to take to ship. Right. And then on the AI agent side, we're seeing some really interesting, we're seeing some really interesting kind of generic AI agent companies come out here. Multion is one of our customers and what they do is you can kind of give multi on just a generic instruction like buy me the pizza and they handle all of the other parts of that. To go Brazil web and buy the pizza. Yeah. What's the name of building their own AI model? Yeah, it's called Multi On. There's quite a few. There's Multi on, there's Minion AI which is also a customer of ours. Pinkfish is doing some interesting stuff more on the enterprise side. So when we think about these kind of like high level agent companies, their ambition is to build the Jarvis, you know, the Ironman Jarvis that does it all for you. And BrowseBase is one of the tools that they plug in with to accomplish that. So I'm excited to see which one of these is kind of like the, you know, the future of our personal agents in our pocket. But across those five categories, there's just a bunch of our customers they're doing. I am frequently surprised at some of these cases I see. There's just so much legacy software, legacy websites that exist out there that just are in desperate need of automation and our customers turn to browser base to automate them because there isn't an API. This thing is maybe 15 years old. Maybe it's written in ASP net. No one's coming to rescue that piece of software, but it's necessary for some sort of function.

Yeah, the API and the UI start to blend with browser base. Right. Like you don't even need an API anymore because the actual human facing product becomes an interface nonetheless. Except for an AI user almost. The UI becomes an AII AI interface. Does that make sense? That is so, so interesting. You teased Paul about the engineering complexity before answering this question and now we have to go back there. I mean you can't just say, you can't just say you maxed out AWS and then pivot. So you mentioned you had to move from a Postgres database to a Clickhouse database. This was very interesting to me. It raised an eyebrow because they are fundamentally different models of databases. Right. One is transactional, the other is analytical. OLTP versus olap. And so what happened there? This is my thesis, if I can venture a guess, and I've seen this across many, many, many startups, is we go with Postgres because that's what we know and we love. And it's resilient and it's robust and it's tested and Postgres is great. So most startups I know start with Postgres and then reach a level of scale where they're like, ah, we need to work in a less relational way. So we're okay with eventual consistency, but we need performance and we need high availability. Right. And so was that the decision point where you all had to switch from Postgres to Clickhouse or for another way of saying it, transactional to analytical or what happened there?

We still use both for what it's worth. But we were using Postgres completely wrong for some more workloads. Right. It worked well up until product market fit. And then basically we just went with let's use as few systems as possible, standardized. And you know, maybe we're not using them exactly the right way. We should in this case. This is for browser logs and session recordings. Our session recordings are actually all text based. It's basically this thing called a DOM mutation observer, it like will observe the changes to the web page, record those deltas and store them in a database so you can watch it playback later. That's an entirely text based recording. It's a lot of text, you know, megabytes and megabytes and megabytes per row. And we were just stuffing that all in Postgres because it worked fine until. Until it stopped. Right. And I remember I got a text from Guillermo, one of your previous guests and one of my investors, the CEO of Vercel. He was like, your, your dashboard is so slow right now. It's like you're out of business.

That sounds like something he would say. Yeah.

And it was like a Saturday. And I was like, man, we gotta fix this. So we, we went super deep and yeah, we just kind of had to bring forward some of the architectural changes that we were going to make eventually or we architect eventually. So now we're using the right databases for what we need. And that's something that I think a lot of startups Often over engineer in the earliest days.

That's true.

And that's kind of like why we made the decisions that we did. I built the first architecture that we had. It was just kind of me all February grinding out and because of that I think I made trade offs. I know we'd have to kind of pay down the technical debt in the future, but if we didn't find pmf, then we, we would never have to pay down. Right. So there's a few other cases of that where we went with maybe more of a managed service for capacity versus like running our own EC2 instances and assigning capacity across those.

What?

Distributed systems are hard.

Yeah, super hard. Absolutely. I have nothing but empathy for that. You mentioned grinding it out in February. I'm assuming that was 2023. It would be a miracle if it was February this year.

We started January. Yeah.

What in, in seven months? You've, you've, it sounds like you've found product market fit and you're thriving with over a million new sessions a week.

Yeah, it's, I mean, I've been thinking about this problem for three years. Right. But when we started browserbase, when I started browserbase, we kind of were on. It was a straight line to validating these things. And going out and serving this stack is so painful that it was really easy. A lot of our customers have built these own stacks internally. They've owned their own browser and they're like, I just do not want to maintain this anymore. They come up with us because we're like their browser team. So it's, it's been an incredibly fast journey and it sounds like it. From zero to, you know, 10 people in our office in seven months has been, it's been a lot of change, but it's really fun.

Have you been doing the whole nights and weekends thing as a early, fast, technical founder?

Yeah, I, I have and I think the, the advantage here is that I've built this before. So I was CTO of my last company, just called Stream Club. We were a browser based live streaming application. So I knew the problem with the stack. I had experienced this firsthand. I tried all the solutions out there and I'd been really dissatisfied with them. So having experienced this firsthand and knowing what the landscape was like of solutions out there, I knew exactly what I wanted to build on day one, which was, okay, let's run browse based. V0 was eventually basically a bunch of Fargate tasks with browsers that were kind of configured nicely and this routing layer that was handmade because Amazon's load balancers don't do websocket routing the way I want them to. And that lasts us for quite a while. It was pretty simple. Had a lot of pain points. Chromium is really painful. It's like a really tough binary to work with. Browse Space is kind of like a database company, but instead of running Postgres, we run Chromium. And it's just not as robust as Postgres is in terms of like developer documentation. Like the, the best in class docs on Chromium or Headless Chromium is this guy like Peter, he has a blog where he lists all the Chrome flags and you can configure Chromium with a bunch of flags. It's not, there's no configuration file, you know, it's, it's flag based config and there's like little bugs like chromium 121 to 120 sticks doesn't allow you to accept dialog boxes. So if you ever get like a confirm like accept or cancel, you know, this little, you know, window confirm, it just automatically hits cancel. And these are bugs that are not documented anywhere, but you just learn through customers building on it. So it's a totally painful, undocumented binary that's not designed to run on a server with this complex stateful distributed system that we could build it all on top of. There's a lot of just pain that you learn with building Headless Chrome and through that we're able to deliver great infrastructure because we, we just experience the pain first and hopefully prevent you from ever having to see it.

Exactly.

And it's feeling the pain, solving for the pain and then parallelizing that solution so that others never, like you said, others never feel it because you've, you've fixed it already. And this is, in a way this sounds very much like open source. You know, like for example, I think of React, right? Like Meta had this problem of we need to make UI updates efficient and so they created React and they're like, okay, we felt a lot of pain with working with the DOM directly. We're going to fix it with React and then we're going to open source it. And it sounds like browser base is exactly the same thing. Especially since you can self host it, you don't have to sort of pay y' all to host those flows. Yeah, I see a lot of overlap here.

Do you agree with that?

Do you feel like there's parallels here between this and sort of just the open source way of thinking?

Yeah, to self host browser based. It's a bring your own cloud situation. So we still install our binaries, our Docker images into your cloud and that is a licensing fee. But I do see a lot of similarities with what you're talking about. Once again, I think people don't appreciate this analogy enough. So I'll say it again. Process is like a database company where you could run Chromium on your own, you could run postgres on your own, but do you really want to? At what point does it sharding and adding indexes and query planning and you know, creating a, a backup system that works really well. At what point is that worth your time? Yeah, with browser base like there's a world where if you're running, you know, if you're Google, you probably shouldn't use browser base for your web crawler. You know, like you probably should build your own at that point. But if you have like a series B, C, D startup and you need to go add this new feature that kind of browses the web as part of a greater part of your product, is that really a core competency that you want to have in house? I often don't think so. And there's times when that's true and we're happy to help support people and we plan to do a lot of work here to help raise up the rest of the headless browser community.

I recently had a project I wanted to build but I failed and I failed because there was no API available and I'm wondering now if browser based.

Could be the solution.

So I'm going to tell you what the project was, the problem was and then we can see if browserbase is a solution.

Okay.

What I wanted to do was it was a project called do youo Know youw Stuff? It was just a, just a, like a, you know, approved concept of what you can do with Genai. And what it would do is it would go to your LinkedIn profile, look at your work experience and your skills that you have listed and then generate a quiz for you, a multiple choice five question quiz and you answer questions and then you get a result, you share it on social media. The problem is LinkedIn doesn't expose any of this information outside of LinkedIn, it's absolutely bananas. Like they don't expose work experience or skills even across their API unless you're a LinkedIn partner. And to be a LinkedIn partner you have to be a hiring platform like Lever or Indeed or something. And if you're not, they just will never give you this information and if you go visit LinkedIn with a browser with even like with Chromium but you're not logged in, then all of this information is blurred out. Even if the person's profile is public, the stuff you want, the work experience is behind a backdrop blur and is just not easy. So you can inspect element and undo the css, but it's still just completely obfuscated and so they know the value of the data here and it may violate their terms of service to do this. But assuming that their terms of service allow what I'm about to say, could I do it with browser based meaning I. I log in. So we talked about sessions with browser base. So I log in as myself, I can see my friends work experience and skills and then I write a script to given a user input of a name, go to that profile and continue the flow, get the work experience and skills and generate the quiz. Can I do that with browser base?

Yeah. Once again, LinkedIn is a very special one. There's quite a bit of case law around logged in scripting with LinkedIn and kind of how that all plays out. So I. On Broadspace we actually don't allow scraping or any sort of. We completely restrict it from the platform. So you couldn't do it with LinkedIn. But maybe I'll point something else like a portfolio website. So if you wanted to kind of pull up someone's portfolio website and extract the experience they have, maybe they have some projects, maybe crawl other links on their portfolio website to go and see like kind of what's going on. Yeah, it's certainly possible Browser base, because there's probably not an API for the portfolio website, right? I mean, unless you're a really cool dev tools engineer. And if so, please email me because I'd love to work with. You do have an API for your portfolio website. But no, I think once again I think about browser as like this generic tool that you can add to your software to kind of augment the capabilities of it. And this may be, you know, in this case browsing the web and retrieving things that APIs don't actually provide.

Yeah, awesome. What else did you have to do to keep up with the scale? And again, just to reiterate for listeners, you have grown, I think four consecutive weeks in a row at 100%, meaning 4x in the last month in terms of usage. I think the normal startup mind can't even comprehend this because most startups I know struggle a lot. And so as you mentioned, you were using postgres Wrong. You had to adjust it and move some of the transactional workloads to clickhouse. What else comes top of mind when we talk about things? You had to adapt your infrastructure to handle such rapid growth.

Yeah. And just to kind of like add another, excuse me, number behind scale there. You can think about it in terms of, like, we measure browser duration as a KPI browser. Like, how long are the browsers running for a customer? That kind of shows that not just much of the value. Like, if someone's running a browser for a long time, they're doing something valuable. We measure that in thousands of hours. Like, it's not seconds, it's not minutes, it's thousands of hours. And it's been pretty impressive to see how that's continued to grow week over week. Because our customers, not only are they doing things that are more complex, that take longer, but there's just more concurrent tasks running thousands of hours.

Hang on a second. That's overall. Right. For an average user, how many hours would their browser workflows run?

Well, generally workloads run in minutes or seconds sometimes. Right. But across all of our users, it then becomes thousands of hours. Right.

That's bananas. Yeah.

So with that, you have a lot of painful things. So for instance, I keep talking about. So one of the things that Twilio had was a phone call API. You know, you make a phone call, the phone call goes through Twilio's pipes, goes out to the other phone on the other side, and that connection needs to stay alive the whole time. It's a stateful, distributed system. So if you wanted to deploy a Twilio, you'd have to wait for all the phone calls to end before the system would fully roll out. Right. So it makes deploying changes much more complex because you have these ongoing connections. In this case, for browser base, it's connections to the web browser, which is the other side of the phone. You have to keep that running and connected the whole time, which is quite painful because it requires, you know, there's like a lot of little gotchas with this. Like in Amazon, the load balancers will actually kill idle connections. So if you make a connection to a web browser and no data is in between it for a certain amount of time, you know, the Amazon NLP will just terminate that connection. So what do we do? Well, we have a heartbeat. So we have to have something kind of consistently going over this kind of connection to make sure it stays alive for a long period of time. We've had to do things where we actually have to have a maximum time the browser runs. Because if we said your browser could run forever, will we never be able to deploy? You know, it's just we, we say, hey, you can run a browser for six hours max. Beyond that, we do have to kind of time it out. Then we have customers who are like, Well, I want 24 hours, 25, 7, 24, 7 coverage of a browser. I said, well run two and cut over at one point. Sorry. It's just like it's, it's, there's problems we haven't been able to solve yet there. It's also just the availability of compute. You know, I think one lesson that we learned was if you're picky about your compute, you either need to buy like reserved instances or have flexibility. So we moved to a much more flexible compute model where we're able to kind of maybe not just use, you know, 2 VCPUs and 4 gigabytes of RAM, but maybe we also use the 4 VCPUs and 8 gigs of RAM or 1 and 2, 1 and 1 and kind of like spread that around intelligently.

Is all of this handled behind the scenes with browser base? That is resource allocation so users don't ever have to reason about VCPUs and RAM. How is that managed behind the scenes at browser base?

Yeah, there's a lot of interesting stuff that we're doing there in terms of allocations of browsers. I mean this whole idea of reserving a browser is how do we make sure we're assigning the right browsers at the right time. And we've had to build the kind of in house, you know, scheduler system. This is kind of like in kubernetes you're often building schedulers, right? Yeah. And I've yet to find a scheduler, an open source scheduler that kind of meets the needs of every single company out there. It's just so, you know, request for startups. Someone should build a scheduler startup, right? That's another key part of the system that is still quite painful to run. An operationalized. One goal we had for August was we want to debug customer issues using browser base. So if you have a customer issue, hey, the browser's running slowly, we should not go to Grafana to try and debug that. We should try and do it within our own product. Because if they can't debug the issue within our own product or if we can't do that, then there's no hope for our customers. Right. So for us, a lot of stuff around like browser performance We've been trying to expose more of that in our dashboard and I think that's like a frustrating thing with infrastructure products. Like if you actually can't. If a customer can't self service, debug their code or their kind of integration, there's no hope for them being able to kind of like solve the issues that they're facing. Live and prod.

Absolutely. Yeah. But if I was to create a system where my users didn't have to deal with VCPUs and RAM and resources and so on, what I would do is use ECS Fargate for auto scaling, or I would just use EKS and just have Kubernetes manage that for me. Is that what Browserbase is doing to have this sort of dynamic resource allocation on behalf of users or am I way off here?

No, we used to use Fargate, but Fargate, we've tapped out. Fargate can like the amount of market tests available in US West 1, US West 2 multiple times. It's actually been really disappointing. So we don't use Fargate anymore. We did early on because it's the easiest way to do it. But the nature of browser is that we don't reuse browsers. We actually kill the individual browser and start fresh each time. That's because it can be tainted. If someone connects and they go to a website and they download files and we just handed it to the next separate customer, there'd be a ton of multi tenancy issues. So one of the values of browse is that we handle the provisioning and the reuse of browsers, or not reuse, but restarting of pods where necessary to really make sure each customer gets an isolated secure browser experience. And that's quite hard because it means we have to be really smart about capacity planning. How do we avoid cold starts here, where a browser is starting when you connect to it? We want to try and have a bit of a warm pool so your browser is ready to go as soon as you kind of create the session. So it's hard. We're solving these problems every day. But I'm lucky to work with some of the best infra engineers that I know. And the team's just been on it since they all joined in April.

This is so good to hear. You mentioned product market fit and as we sort of continue the discussion, I'd love to move more towards the business side as well because like it's combining great tech with great business practices and I see that y'. All, I mean again, I can't emphasize enough 4x in 4 weeks. Bananas. Right? To that end, you mentioned product market fit a few times. You seem to be convinced that you have it, which makes me super happy. How do you know you have it? And the reason I ask is I've spoken to. This is founder season, right? We talked to like Brandon Bayer from Flight Control, as you mentioned, Guillermo Rauch, Matt Bilman from netlify. We talked to all these folks and one of the things that Brandon said was you can identify product market fit where it's not so much you like Sisyphus pushing a boulder up a rock, but it's more you're trying to chase this thing because it's just taken off and you're trying to keep up with how it's growing. Would you say that's how you've sort of identified you've hit pmf or is there more to it?

Yeah, I actually just spent six weeks with this program called the PMF Method from the First Round team. First Round is a venture capital fund. They have some fantastic materials. They're not even investor base, but I really enjoy this thing. And they talk about there's actually five levels of product market fit. It's like nascent pmf. Developing pmf and PMF isn't just this thing that you hit once and you're done. But actually you go to have extreme product market fit and that takes years to get you right. So I think that it's like frustrating. It was frustrating for me as an entrepreneur saying, well, what is product market fit? It's a vibe. No, I want like clear, like milestones of product. So for us, we know we have product market fit because we have, you know, repeatable motions to grow our business that work, you know, every single time we have strong customer retention and people keep signing up and it doesn't go away. Even though we don't really do much in way of marketing outside of the occasional podcasts with with you. Right. So for us, pmf, at least developing PMF, the earliest levels is like, do you have 10 customers who absolutely love you and would not if you shut down, they would be very upset. That's a good place to start. And from there, can you find a hundred of them? Do they tell their friends about you and do they come use your platform? I kind of like try to stick more with numbers and metrics as opposed to just saying we're chasing boulder. That feeling is true. And certainly I think one feeling to describe product market fit is you feel like you're missing an opportunity because you're not moving fast enough. Because all of a sudden you've spent this whole time validating, building and saying, hoping the customers come, and now you're like, I can't service them fast enough because we have so many requests and asks and things we need to do. That's probably a good sign of pmf, but I once again would focus on the clear metrics of do you have 10 customers who absolutely love you? It seems small, but PMF isn't necessarily about the scale. It's about the deep, deep need for your product where people will buy over anything else.

Yeah, yeah. And it sounds like you have those 10. I have to tell you, just through this discussion, I'm super excited about trying it out for myself. I haven't yet. I have seen all the ads and the marketing, but I did want to talk to you first to really. So part of the naming of this podcast, just as a side note, is contagious code. And there's many people go like, oh, it means like with tejas in Spanish. And there's many meanings, but one of them is honestly is I want to get whatever my guest is really passionate about. I want that passion to become contagious to me and then to the listeners. And indeed, I feel super motivated to go, like, use browser base to further automate my podcast. I think there's a lot I could do here, so I'm really excited about that. You mentioned you're growing the team and it's on its way up. What qualities do you look for? What are you looking for specifically? I think you've got growth engineers on your website. I don't even know what that means. So how are you growing? What do you look for and what does culture fit look like?

Well, we haven't hired anyone who's not an engineer. Every title has had engineer as a suffix. It kind of goes to show that the number one priority is at your tech. You understand what browsebase does. We are a technical product. We're a developer tool. So everyone needs to understand that and probably should write a little bit of code from that. You know, we have people who are focused on different parts of the problem right now on the website. We have two roles open, actually, both of which have offers out. But we're going to keep growing the team regardless, which is growth engineer. So I'm going to focus on growing our top of the funnel. So they're writing code, they're writing docs, they're kind of posting on Twitter and saying, hey, here's built with Browserbase. They're helping inspire our Customers.

Some would call this a developer relations engineer. Do you agree?

I like developer relations. I have a ton of friends that do Devrel and or developer Pantrils and I think that we wanted to call it growth to make it really clear that the goal here is not just relations, it's actually to grow the product. You know, Devrel can be hard because it's like I'm building great relations and then there are people, they cut dev rel orgs at companies.

Yeah.

And for us like the KPIs, we need signups, we need to make sure we have new people using crossbox every single day. And that's why we've called it growth. I. We did Devrel. I'd actually care more about the role being tied to how. How is our GitHub stars or how many conferences are we going to per year. People love us. You know, what's the. We ran a survey of developers. What do they think of brought that's more of API, put a role there on the sales engine side that now it's the complete opposite to the bottom of the funnel, you know, so how can we have someone who is joining the Slack channel with a customer and helping them build their poc and if they have a feature that's blocking them, maybe they're actually building that feature themselves to help out with that. They're very oriented towards the customer. All of our engineers talk to customers but this person's like especially so going to be the customer, customer's best friend and be the first person they talk to when they need to debug something. And kind of you can say this role is very similar to like a customer support, a customer success manager and you know, a solutions architect. But as an early stage startup, every role kind of COVID quite a bit of ground. Right. So that's what we kind of designed with these roles is that you get a lot of scope and you're going to get, you know, a lot of scale here.

Yeah.

And that's what's appealing about working at Browserbase. You know, it's kind of early stage startup is that you get to do a lot of things that maybe you wouldn't get to do otherwise. The larger company company. With that comes a lot of work. But we think the work is worth it because you're going to learn a lot and be in situations that you've never been in before.

Yeah. And you get to actually move really, really fast. I mean at one point I worked at Spotify which had like nearly 5,000 people and you notice the pace and the time dilation in large companies. I mean, you were at Twilio as well. I'm sure you can, you know what I'm talking about. I saw, I think somebody posted on Twitter. I don't know if it's, it's still there, but I believe there was a job posting for AI Engineer at Browserbase also, which this is an interesting one because Sean Wang, AKA Swix, wrote this whole thesis on the rise of the AI engineer, a job title that didn't previously exist, but now we're seeing even OpenAI hiring for literally the job title is AI Engineer. That's interesting. What does that mean? And the reason I'm asking is there's so many listeners of the podcast, even though I have episodes dedicated like an hour and a half of me just explaining what this is. People going, oh, I could never be an AI engineer because I don't know any Python or linear algebra. So what does AI Engineer mean? What's the requirement at Browserbase?

Yeah, so for this role, this person will be a major contributor to Sachan or open source SDK. So a lot of the work they do will actually be open source, which is really cool. And while it's probably good to know a bit of Python, a bit of JavaScript, that's what the SDK will be in. We don't necessarily expect someone to come in here with a machine learning engineer background. Right. An AI engineer for us is actually very much an applied AI practitioner. It's someone who's been playing with large language models since GPT3 came out. They understand the best practices for rag with this practice for prompting, they read all the papers and they stay up to date with the models. They know which model is right for which job. It's someone who's just spending all this time with large language models and tinkering that can kind of come in and help us build this framework for automating the web using AI. So it's a really awesome role. We're really thoughtful about who we work with here. We want someone who builds something, who's built things with AI. Maybe they've actually worked with another startup for a while and touched something with large language models, but it's not someone who's training their own model. I think that's actually the difference between an AI engineer and a machine learning engineer is that AI engineers are much more applied AI and then MLE machine learning engineers probably much more on the model training and the data science side. And that's kind of where I see split. I'd put AI Engineer much closer to Prompt engineering as well. A Prompt Engineer, which is the title we've seen a little bit more of recently.

Fantastic.

Thank you so much. I think we need collectively as an industry, for those of us working in the AI space to keep reiterating that because there's so much fear, uncertainty and doubt about this title. And I'm so glad that you said that because that aligns exactly with what I've been you telling people about AI engineering. And it's always nice to get some validation. Now you mentioned also I believe in your website that you all work in person in San Francisco.

This.

How is this received? I have to imagine people go like, what, y' all don't do remote? That's so bad. But also I've been in in person positions before in offices and I can tell you, I can tell all the listeners that there is nothing like it. There's nothing like coming to work in the morning and having your teammate tap your shoulder and go like, dude, you want to see something cool? Look at what I made. And then having this in person electric exchange. So personally, I see a ton of value in person, especially at an early startup, but also a ton of value remotely because then you get the best talent from all over the world. Indeed, we have episodes with Cal.com's founder Pierre, who their whole company's remote first. So can we maybe talk about some of the trade offs there? There was also, and I'll lead with this, which is there was. You've probably seen this recent interview with. I think it was Larry Page from Google who mentioned Google's lagging behind in the AI race because people are not working from the office, which I think is absolutely absurd. But anyway, all that to say, I'm curious to get your thoughts on that topic.

I think it was Eric Schmidt at Stanford who gave that talk. Yeah, but you know, building a company in person is so hard. There are so many great candidates who I love and I want to work with but, you know, can't move to San Francisco for a variety of reasons. They may have family, maybe they have a lifestyle, something where they need to be in the city they're in. Us choosing to be in person is not me rejecting them and saying, hey, like, I cannot work with you because you're not great. They're all really great collectively as a company. We've just all chosen to work in person and we do that because it actually allows us to focus more. You know, we can come here, we turn it on, we're working here. In person. And when people go home, it actually creates this nice separation where they actually can kind of disconnect from work a little bit more. And people still work in the evenings. Here we get, you know, pull request opened up at 9. I was doing course up at 9pm last night. Like, that's, that's okay. But it allows us to kind of at least close the laptop. Whereas, like when you work remote, I think it's really hard to create that separation for some people. And honestly, it's just been really fun for us to all be in person in San Francisco. This is where all of our customers are. We all live in San Francisco anyways, so why not create an amazing office? We're moving in just now. So you can see it's a little bear behind me because we're still filling out the space. We got something way bigger than we needed. Once again, it's a cultural thing. Like every morning we all decide to put pants on and go into this office and work together. And that's almost like a bit of a sacrifice we make for each other. But we do that because we believe in this mission and it's just the working sale that we've chosen. And my aspirate and potential employees at Browserbase is always like, if you don't want to work in person, you shouldn't work with us. That's okay. It's not a judgment on you at all. It's just this is what we do and if that's something that's kind of interesting or exciting to you, then we'd love to work with you because we really love that way of working. But I think it goes down to like remote first companies. People really love the remote first way of working. You should go work there. I think they're comparable. People do a lot of engagement bait around which one is better. I don't think one is better than the other. I think it's just people have different styles and our style has choosing to be. We work in person and one is not better than the other. That's where I think people get a little bit too Twitter engaging.

Yeah, this is exactly why this is nail on the head, Paul. Exactly why this podcast exists. There's so much like vitriol for literally either side. When people fail to recognize, hey, we're blessed to enough to have the luxury of both. Just choose one. And I think that's.

That's huge.

So many people can't do that. Like doctors, could you imagine if they had this choice of like, I'm just going to Be remote today or, you know, it's, it's incredible. So thank you for drawing the, the attention to the nuance there. That is, that is so cool.

The problem with our industry is like, people tend to like really politicize every single decision. It's like it must be in person remote. And I think, I think hopefully like that's not how boundaries actually think. It's just how the loud people on Twitter think, you know, so don't let that pollute the decision making process of how you live your life. Everyone has different styles.

Everyone get off Twitter. And also, by the way, I'm glad you mentioned y' all put on pants and then go to work in the morning. Right. Kind of important. Okay, let's talk about money. Exciting news, Paul, you have to share. I'm gonna let you share and then we can talk about it in more detail.

Yeah, so, so, I mean this, the story of browser base has been. We started in January, you know, late January, raised our first round about 1.9 million.

I regret not being part of that.

Round, unfortunately, we'll always issue the next one. Right. And then shortly after that, we raised a seed round relatively fast, but you know, about another 4.5 billion. And you know, now it's really exciting. We'll be announcing this when this podcast comes out, but we raised our series A round eight months later. All in. We'll raise, you know, about $27 million.

Oh my goodness.

And it's actually quite rare. I looked at this stat from Carter recently, like less than 3% of startups raised their Series A within 12 months. And frankly I was very hesitant for us to raise a lot of money because I know that what that can do to a startup. But what we've done is along every step of the way we've raised, as we've gotten higher conviction about what we're doing, about how the world will change in the direction of software using the web. We've kind of raised along those things and just the space has evolved really fast. So we are raising a Series A round is an additional $21 million to our 6.5. We have total so far and I have just two amazing investors going to come join us. Bucky Moore, who actually led our seed round, he's at Kleiner Perkins on the board of netlify, he'll be joining our board. And then Reed Christian, who's on the board of Vercel from crv, he'll be joining our board as well. So Bucky and Reed are co leading this round, which is super exciting people. I've known them both for over a year. Really, really great minds on the dev tools, diverse side. And yeah, we're ready to go. Continue to serve our customers, continue to pay big Amazon bills and continue to improve and be craftsmen of this infrastructure and hopefully make some just great investments in open source as well.

Incredible. And help the web become a place where AI does most of the work for us so we can live our best lives. That is so cool. Congratulations. That is really, really exciting. Exciting. You mentioned some apprehension around fundraising. You said, oh, I wasn't sure if I wanted to, but the more I see the validation that this is the direction of the future, the more I lean into it. And you said you were apprehensive because you know what raising too much or too often can do to early companies. I think a lot of our listeners don't know what such raising can do to companies. So can we elaborate on that? Like, what happens if you raise too much or too soon or both?

Yeah, happy to. I am. I'm a very lucky person as I live through three hype waves now. I started my first company in 2020 during what we were calling the passion economy, where creators were going to change the world and all these startups popped up to service them. Hop in was a company that raised alongside us, also in the virtual events category. And I love that product. That team's really great. They also raised a lot and had to go through a lot of hard layoffs when they were able to hit their goals to prolong their Runway. So sometimes people raise really aggressively and then grow really aggressively, but then the market that they're in doesn't kind of rise to meet that occasion. And I think that's something I've just been mindful of because I lived through the passion economy. Then all the web, three startups that kind of rose and fell, and now kind of like the first wave of AI startups, and now we're kind of in this later second wave. So it's. It's really important to kind of know why you're raising additional dollars and how you plan to use them for us, like, we'll continue to grow aggressively, but probably not to the point where we have 100 people working for us. You know, I think like, 20 is a really good number that could see us maybe 25, but really growing along with our customers and not getting in a place where we. We get stuck with being a really big company in a market that's still kind of early. So with, with raising too much, the downside of that is like you may have to do layoffs. Maybe you actually aren't able to sell the company because you've raised so much money. The price to sell it is way more than it's actually way less than it's actually worth. It turns out like actually as you scale a company quickly, you, you move slower as is, you and I have both seen that really with large companies. So like actually you may strategically be in a disadvantage if you grow the company really fast and the market changes very suddenly underneath you. That's something that happens kind of often in these early markets.

Yeah.

So I mean I think even personally with Browser Base, it wasn't until our seed round where I personally said I want to build a category defining infrastructure company. I want to build something like a Twilio or a Stripe or a Cell. And to do that, to be category defining, you need to go the traditional venture route. You have to, you know, raise enough money to build a team that can sustain a brand new category and invest in it to help customers kind of grow. I see browse infrastructure being a category similar to how telephony is a category and payments is a category. Browser infrastructure is primitive and for that reason I wanted to make sure we go raise a series A to kind of establish the category and say, hey, we're putting serious capital behind this thing to not only support our customers, but also support the other builders in space and really see what we can do when we can reliably automate the web with this browser infrastructure. Behind the scenes.

Incredible. Thank you for that. Yeah, I think a lot of people didn't quite make the connection between the trouble of selling a company later after it raised so much and then it's not worth very much and also the obvious connection to layoffs. So I appreciate you drawing those parallels. Incredible. Paul. I'm really excited about Browser Base. I think this is going to be something really great and I can't to wait, wait to try it. I, I wanted to ask you, you've been a founder now many times over. You said you've been a very lucky founder and you've made it through a few hype cycles. Garner has the hype cycles. I think that's what we're talking about. Right. And, and there's been a lot of discourse these days that in the Garner, for those who don't know, garner hype cycle is sort of like a, like a, an upside down. So a spike and then a dip and then it flat lines. So it's a peak and then a dip. So it's the peak excitement and then disappointment and then just normalization. So it's like 100% negative. 100% and then it continues at 50%, so to speak, of hype around various topics. This exact cycle happened with things like Web3 and cryptocurrencies and a lot of people are saying now, hey, AI is in its like disappointment phase. Do you agree with that? I certainly don't. Mainly because I, as I mentioned, I use perplexity every day. I don't use Google anymore and I build really great. Part of my job is to build things with AI, tons and tons of things and explore the boundaries, where does it fall apart, how can we fix various things, how do I create like smaller specialized, fine tuned models, et cetera. So I don't see the AI Winter, but I'm curious if you see that and if you're sensitive to it as you continue to guide your company.

Yeah, it's a great question. I don't see it either yet. You know, once again, having lived through the passion economy and Web3, I think there are some startups that in the AI space that maybe got a little bit too aggressive too fast.

Like the rabbit R1 and things.

Yeah, I'll be hesitant to maybe name any of them on this podcast, but I would say that I think there's some startups who got a little too aggressive too fast. And with a developing market we also need to accept that these companies need to develop alongside of it. And the worst thing that you can do is I think it's fine if you raise a lot of money as long as you don't spend it unnecessarily. And I think I've seen some kind of financial blunders by some startups that have just really left them in a place where they've over invested in a market that actually isn't really there yet. So as founders it's our job to have a vision of a future, but once again be very pragmatic about what we could do about it right now and set ourselves up for this. Like with browser based. I actually think that the next generation of foundational models will really unlock a lot of our market here. So you know we're going to grow but we need to see more innovation on the foundational model side to really see the true capabilities of these AI agents. And you asked me about the are we in Winter? I don't think so because it just is so much actual usage of these tools. I think that there's a lot of the end, the Number of companies is quite large and there's many people trying things and that may be the pain point. There's a lot of noise, but if people are actually using your thing and it's providing value, I can't imagine that's not valuable in some way. So it's powerful. It's hard to live. I think people probably said the same thing about the Internet being started. They're like, oh, these Internet companies are kind of crazy. And for what it's worth, the dot com bust was real.

Right?

So that may be something similar. But then we had Google, Facebook, aws. All these amazing companies come out of that kind of like paradigm shift. I think we may see some similar with AI.

Fantastic. I share your thoughts exactly. And so I'm really happy about that and also let the numbers do the talking. Your company again, I will emphasize, grows 4x in four weeks in terms of usage. That means how can there be a winter if people are using things? I'm super happy about that. I am also bullish on this. All right, final few questions. The last one I've been saving is a bit of a doozy, so I won't get there yet. But I wanted to ask on behalf of listeners for those who want to try out if the contagiousness has caught them and they want to try out Browserbase. I'm assuming they just go to browserbase.com and make an account. But I'm sure there's going to be questions about the pricing model because obviously I'm assuming they want to maybe sign up for a free trial or build a side project or maybe build a business. So in light of recent events and investments and things, what is the pricing model and how can people try out browser base today?

Yeah, it's super easy to try actually. So if you go to browser.com and sign up, you immediately get dropped into this IDE where we've pre written a browser script for you. We can just click run and watch the script go and check off some to do list items and interact with the webpage. You get to see it right as soon as you sign up. And you can do that for free. We have 10 free sessions you get after that. We do require a credit card because we're infrastructure and you know browsing the web can be expensive. So we have a hobby plan, a startup plan and a scale plan. The hobby plan starts at 39amonth and that gets you some amount of usage. Generally I think it's 200 browser hours and 2 gigabytes of proxies the startup plan gets you a little bit more for $99. And the scale plan allows us to kind of customize the pricing based on your needs. If you go over the amounts you're given in your plan, you get an overage pricing. It's the same. It's not a markup. It's the same price you paid within the plan. Just kind of set up by browser hour. It's $0.10 per browser hour and then $10 per proxy gigabyte. That's the pricing plan. But if somebody ever wants more free sessions, they should just email me. Paulsebase.com like, we're happy to support more free usage. We just like to talk to people, once again, know the customer before we get that out because there's a lot of risk for abuse on browser base. You know, you can have people doing a lot of bad things. So we do have to be really mindful of how we charge for our product to make sure we combat abuse at the earliest days.

That's cool. I'm surprised that there's a free tier because, like, I'm seeing a big movement these days in devtools companies to move towards. Yeah, we're not doing a free tier and just being totally okay with that. And I think that's in many ways the right move. Because for some reason, Paul, I don't know why developers earn these, like, exorbitant salaries, but will just be very hesitant to pay like $10 a month for some infrastructure service. And I find that really weird. So on your website, browserbase.com there is no mention of a free tier. And I think there's some wisdom to that.

Yeah, we don't have a free tier. For what it's worth, you have 10 free sessions. We give you like free credits. But yeah, it's interesting. I think developers are hesitant to pay because there's so many bad tools out there. They've just been burned so many times with the tool that doesn't work or an API, it's unreliable, that they don't want to pull out their pocketbooks unless they really trust this thing. We hope that, you know, being able to try the product a little bit before you buy it, but not have, you know, this indefinite free trial period. You know, commit to us and we'll commit to you. And if it doesn't work, we'll refund you. We have a pretty generous refund policy.

That's awesome.

Yeah.

Is there a community channel like Discord or Slack where people can go and ask for help and be part of A community or is it just literally. Just email me and I'll figure it out.

So we have a chat widget built into the product where you can ask for support and oftentimes I'm the one that's coming out there to answering it among some of our other team members too. We don't have a Discord and I've actually been kind of hesitant about adding a Discord. Maybe this is the boomer in me. I'm so bad at Discord, it's just not in my DNA.

I hate Discord.

I found that some of these Discord channels for developer tools often can become quite, quite, quite noisy and also like under invested. So we actually, when people join the startup plan, we give them a Slack channel and they can kind of talk to us in Slack. We're very responsive on the support chat, if you open that up. But honestly, Twitter is our community. You know, if you just tweet at us like, we, we kind of get. That's a town square. That's where we get really involved there. Awesome. We, we. I may eat my words. Eventually we'll have a Discord. But for now, I've just found it really hard to execute this board extremely well without it being kind of this abandoned thing that people just have and no one really talks in.

Yeah, no, I'm with you 100%. I struggle with Discord. I only use Discord for gaming, actually. And if some conference wants me to be a part of their Discord. Right, all right, last question maybe. And there may be more follow up, so I'm not committing to that. But this question is something I've been asking literally every founder who's been on this podcast. And for those who don't know, this is founder season seven. So every Monday we have a different founder. And we have had this now for like, I don't know, four or five months. So here's the deal. Some time ago I was sitting with some founder friends, right? And they were sort of lamenting and going, man, nobody prepares you for this. And I thought, that's such an interesting statement. Say more. And they were like, you know, it's so different, but it's also unexpected. And they were like, I wish I knew this and I wish I knew that. Now you've been a founder, what, three times over? Over. And I was thinking, based on our discussion with those founders some time ago, we're used to, as engineers, we're used to living standards. Things like HTML and CSS Golang, they have language specifications that say this keyword means this thing and this attribute gives you that outcome. And they're objective specifications for how the language works. And they're often living specifications, meaning as iterations happen, as versions increase, they get updated over time. So everyone's experience is unique. But I have to believe that if you zoom out and have a broad enough perspective, you'll notice overlap. So with that, the big preface to my question being a repeat founder, what are some things, if there was such a document like this, like a living standard for founders to be prepared to be a founder, what would you add to this document? What would you hope that is in there for newer founders who are maybe starting their first company?

It's funny because I almost there's probably not anything you can put in this document at all. You know, I think that there, there's very little. I don't consume much founder content the second time around because each company is so situational and different in a lot of ways, right? Like no amount of YC YouTube videos is going to prepare you for starting a company. It's just not. It's worth watching them because they're entertaining and they're interesting, but they aren't going to give you the playbook. What will give you a playbook is really understanding a business that you like, understanding other businesses that are similar, that have been successful and why they're successful, and taking the lessons you've learned from other businesses and applying them to yours. So I mean, if I gun to my head, what's it in here? I'd say you'd have to have an encyclopedic knowledge of your industry. You need to know who the best companies are out there, what made them great. Why is Stripe great? Because Patrick Collinson actually installed Stripe onto people's computers when he first started. And from that he learned a lot about the pain points and they spent a bunch of time brute forcing great developer experience in the early days. And it's just an amazing story, right? And then they also execute well from a product abstraction perspective. That's why you consume the founder content. It's to learn what people learned in your space. But I think these generic platitudes around only hire a players. It just is kind of too generic to be valuable to founders. So maybe the other thing is know your entry really well, but also cut off the noise. You know, there's no blog post that's going to tell you how to run your company. You just have to know how great companies are run and learn how great companies are running and emulate that until you start to figure it out even more and you'll have twists on stuff, you know.

Sorry, no, I was just going to double down on that. How can one, you said that twice, Know how great companies are run or know your company well, but the first time you said, understand other companies that you like and deeply understand you, your company. How practically, how can one do that? Do they just like sit down and think about it at length? Do they ask questions to other founders of companies that they.

I do a lot of studying, like for Stripe. I'm using Stripe a lot as an example. I think it's one of my favorite companies out there. Like I've studied and written about their product Roadmap or Datadog. There's this really cool graph about Datadog out there that you can find which shows like the product they've launched. And you can kind of see they had like one and then they built all these layers of products on top of that one and all of a sudden became a much more defensible company because they built this vertical stack as observability and APM alerting and stuff. These companies have websites and they have blogs and oftentimes founders write about the way that they're building companies. They try and like, like share the knowledge of this podcast too, that we talk about this stuff. So I, I turn away from generic founder advice where someone is saying, here's how you become a great founder.

Yeah.

Because it's often from grifters, you know, that are like, yeah, trying to sell you a course or something. And I would turn towards people talking about their businesses because they're just very excited about their businesses. And from that you learn about business like and like specifically the business in your industry which is for this podcast, probably dental infrastructure.

Yeah.

Awesome.

Yeah, that's my answer.

I love that your answer is basically, listen to this podcast.

Wow.

Yeah, there you go with that. Listen, Paul, this has been so great, honestly, thank you so much for coming on. You've taught us not just what browser base is and why it exists, but also how it's built such an awesome deep dive from someone well versed in both business, who just raised a series a company. Congratulations. And technology and it's such a treasure trove of information. So on behalf of myself and all the listeners, thank you so much for coming on and sharing all of this with us.

Yeah, thanks. It's good to be here.

Thank you for joining my discussion with Paul Klein iv. I hope you enjoyed it as much as I did and I hope you got to dream with us a little bit about a world where developers can easily deploy a fleet of browsers for AI agents to use and these agents go off browse the web and do great things for humanity. I hope you also learned about product, market fit and the business side and you celebrate with us the Series A that browser base has raised and look forward together to the things they'll build. If you're learning from and or enjoying this content, then a great way to support it at really no cost is to like the video if you're watching on YouTube and subscribe to the channel, maybe share it with your friends if you're listening on Apple or Spotify. Then if you leave up to a five star review that would be super helpful. But I said up to a five star review so honestly, you can leave whatever you want, I don't care. Ultimately I do this for you and also for me, but I want to make this information available so that we can learn, we can grow together and we can really celebrate the beauty of engineering. And so to that end, thanks so much for being a part of another episode.

Thank you for being a part of.

The podcast, and most importantly, thank you for your interest in engineering.