Building the Browser Infrastructure for AI Agents with the Founder of Browserbase

Well, I always think a startup should be a means of last resort. You shouldn't start a startup because you want to start one. You should start it because you have a burning problem you have to solve. I saw that Headless browsers were going to be a critical primitive for this new world of software. And in the end, the product we're building is a product that I love because I've experienced these problems firsthand.

From Notable Capital, this is Founder Real Talk, where we get real about the challenges that founders and startup executives face and how they've grown from tough experiences. Founder Real Talk is part of the Notable Capital family of podcasts and you can access all our podcasts@notablecap.com I'm your host, Glenn Solomon. Without further ado, here's today's episode.

Hey everyone, I'm Glenn Solomon, managing partner at Notable Capital and I'm here with my colleague Dan Kahana.

Great to be here, Glenn.

Awesome to have you. And we're excited to have the co founder of browser based Paul Klein with us. Thanks so much for joining today, Paul.

I've been waiting for this for a long time.

Well, we first met, we met you, Paul, about 18 months ago. You responded to a post that Dan and I put out on the rise of Serverless. You invited us to read your post that you had put out a bit earlier entitled Death to the Back End. In that post you stated, I remember reading it, you want to build developer tools that give front end developers superpowers. And that was music to our ears. Several of our notable companies, companies you know well, Vercel, Neon, Ingest, they share that vision and we're really convinced of the power. It's why we're excited, so excited about Browser Base and we've been so excited since learning about what you wanted to go build. And today we are thrilled to announce that Notable Capital has led Browserbase's Series B funding and on behalf of the entire team and Dan, we're really excited to finally get a chance to partner with you.

Paul. Yeah, it means a lot to us. It's super exciting because I think the team at Notable has been there every step of the journey for Browser Base from even before inception in the LinkedIn DMs with Dan, all the way now to being here in the office with the team. It's just really exciting to be a part of the Notable portfolio. I know when I look at the investments Notable has done, they've backed the best companies in our category in infrastructure and dev tools. So for Browser Base to be joining Those companies is a huge honor for us and we're really excited to partner with the team and kind of keep pushing forward because we're still at the very beginning of this journey. There's a long way to go and.

We'Re really excited to take that journey with you. We are similarly honored to have you join the portfolio. But let's start. Maybe you could just level set for.

Us, tell us a little bit about.

What browser base actually does and we can go from there.

Yeah, of course, from a very high level I love to think about what are the primitives that developers need to use to build software, right? So you might have a database, you might have some sort of server for hosting your application. And there's this future of software where software is going to go do work on your behalf. This is AI future of software. Right. And if software is going to go do work on your behalf, software needs to do the same types of things that we do. And a lot of the work that you and I do, I know you guys are probably on crunchbase all the time, right? You're browsing the web, you're interacting with websites, interacting with web UIs, clicking buttons, downloading files, you know, submitting forms. And browser base is allowing, you know, software to control a web browser with code. We are a base for your browsers. We're headless browser infrastructure. A headless browser is a browser that runs on the server. So what we really specialize in is how do we enable developers to programmatically control and interact with the websites that exist out there on the Internet, there's billions of them, and integrate that into their application to build features that in the end allow users to do less work and hand it off to the software that might go submit that form for you, that might file your Delaware taxes for you, that might go and check the nursing credential on the US California nursing website. These are all the busy, boring work that people have to do in their day to day lives and developers now can automate them with software and with browser base. So especially with the rise of AI, it makes it much easier to programmatically interact with the web and do it dynamically. So we think we're building this primitive for the future of software, really focused on the automation of work.

Super interesting. And I think part of what was really interesting to us seeing you evolve over the last call it 18 months is when you started browser based, the AI market and the headless browser market were in a pretty different place. And I think you've been able to be Sort of forward looking while also being reactive to new launches like OpenAI's operator model, all these other sort of computer use models that have come out. How do you think about balancing the long term goals of browser base with sort of the day to day changes that we see in the AI landscape?

Yeah, I don't think much has been too surprising. It seemed inevitable that there would be a model that was launched that actually make it easier to control UIs. That's what the computer use model from OpenAI does, or computer use models generally do. They make it so an LLM actually can see the buttons and click on them. Right. And that's great for us because we're an infrastructure company. Everything that happens above the fold where models are getting better, faster and cheaper, that makes it easier for developers to build more sophisticated tools using a primitive like browser base to offer the browser. So we always kind of had a feeling that models were going to get better, faster and cheaper. And what can we build alongside that that can be robust standalone company? The browser based infrastructure platform really kind of stood out there. The thing about companies that grow fast is that you tend to have a pretty clear vision and you stick to the plan. Even here in the room. In this investment, this was all the plan from day one was to work together. I think that we're trying to do a lot of category creation here. Browser infrastructure is not a category you saw on the market map in early 2024. And the way we do that is by evangelizing. You know, we talk about the things we're seeing and with browserbase, which is quite cool, you know, we have a thousand customers now and that's going to be part of our announcement of the series B. Through that thousand customers, you really get to see the bleeding edge of how people are doing things. And back in 2024 I'd hear from my customers like, hey, we might train our own model to do this. And I was kind of curious about that. I was able to learn. So part of the compounding effect of browserbase is like through the aggregate of our customers, we, we see a lot of insights that really help inform our product direction a little bit earlier than people might see them in the public market or the real market. So for us we just listen to our customers and that allows us to keep innovating because they tend to be pulling us along and they tend to be quite innovative companies and we're just trying to keep up.

Yeah, I mean, I think that what we've seen kind of consistently over investing in dev tools and especially over the last couple of years that the best companies sort of get better as the models get better and have sort of differentiated access to customers and ability to iterate from there. I know you've been thinking about sort of the headless browser market for a long time. Maybe walk us through kind of what was the initial insight that or the experiences that made you want to sort of reinvent this market. And what have you seen is sort of broken about the way AI accesses the web sort of prior to browser base?

Yeah, you know, I think I'm a one trick pony these days. It's really only headless browser infrastructure. And I really grew to understand this problem as CTO of my first startup. It was a venture backed startup during COVID and my job was to build some software. And by building that software I had to understand this thing called a headless browser. And instead of finding product market fit, we spent a lot of time on headless browsers. And I became very opinionated about how this technology works. It's a bit of a hack if you think about it. You're running a web browser like the one that we run on our laptops in a server environment, an environment it wasn't designed for. And you know that's, that's kind of very unique in infrastructure database companies like a PostgreSQL, it's designed to run on servers. Our core primitive browser was not. So there's a lot of stuff and a lot of improvements we can make to the browser itself, the scaffolding around it, the infrastructure around it to make it a much more seamless, scalable performant experience for our customers. And a lot of the things that we built have been informed by my pain points as a founder of a company that was tasked with operationalizing thousands of headless browsers. And some of those things are like. Observability was a really important thing for us from day one. And when we looked at the category of companies that already exist out there, nobody was building a stripe or vercel like experience for headless browsers. It was a little bit more mom and pop shop kind of setups. And I looked to the companies that inspired me, these great infrastructure companies, and what do they all have? Observability is a really important part of great infrastructure because as a developer, when you're building on top of infrastructure platform, if something's not working, you need to know exactly why it's not working and how you can fix it and really make sure it's on is it your code or the infrastructure that's not working. So we added a lot of observability to browser based like session replay, really robust logging, network request detection, saying what network requests did the browser make? All those things kind of came out of my own frustration of being a developer who needed to work with a stack. But also inspiration from, well, what are the great companies and infrastructure doing for their respective verticals and how can we take those best practices and bring them over to Browser Base?

Paul, let's shift gears a little bit. You as a developer have been a builder inside of some really innovative companies like Twilio and mux. You alluded to the fact that you've started other companies in the past. So you know the allure of startups maybe is, is, is something you're well acquainted with. So how did the idea for Browser Base come about and what led you to this moment? Why did you decide this is the company I want to start? Because I'm sure you've seen lots of opportunities out there. Why Browser Base?

Well, I always think a startup should be a means of last resort. You shouldn't start a startup because you want to start one. You should start it because you have a burning problem you have to solve. It does all come down to I saw that headless browsers were going to be a critical primitive for this new world of software. I knew that the technology just really hadn't been invested in. Now rewind to the beginning of my career, being an intern at Twilio's IPO and seeing Jeff Lawson up on the stage at all hands. There's a lot of inspiration from great founders who've built primitives and primitive developer tools, platforms and seeing the success of those businesses, but also the really powerful opportunity you have when you build a horizontal platform. You're going to discover really unique ways that people can use your solution to build compelling things. And on Browser Base I've seen that. I continually see new use cases like there's a 55 year old company that has never hired a developer before until this year. They hired someone to use browserbase to automate some back office process they had of aggregating gas prices along a route. And I thought that was really compelling because it's not just the darlings of Silicon Valley that are using this cutting edge technology. These are large companies, generational companies that are sitting outside of Silicon Valley that are reaching for these new primitives and want to kind of build the future of software. And I'm just very thankful to have a part of that journey and in the end. The product we're building is a product that I love because I've experienced these problems firsthand and that's really what keeps us moving forward is saying, okay, how can we continue to improve our craft? How can we make our product better? How do we make this primitive that is historically very flaky, non deterministic, actually be reliable and bulletproof for our customers? So that has all kind of come together to really push us to aspire to be like the great companies in infra. How do we become the Twilio, the Stripe and the Vercel and what have they done really well. And I'm lucky to have the founders of each of those companies as investors in browser base and they've been big mentors to, to me as I continue to build this company.

Was there, was there like a moment, a spark where you said, ah, like this is the company I want to found. Totally understand. And having a thousand customers now I'm sure you are well on your way to continuing to innovate in this area. But if you go back to the, to the moment when you said, yeah, this is the company I'm going to start. Was there, was there like any, any like long late night where you like really were upset with the state of the technology and you mentioned last resort?

Yeah, it's funny, I did write, you know, this memo, a web browser for AI. I was doing like a monthly memo or newsletter, something post. I remember I was, I was running up on my deadline and it was a Sunday in November and I had to write my weekly, my monthly memo. And I kind of sat down and was really unique about this day. I don't think I've ever told this story before. I don't. You know, I'm not a big gambler, but I did like some sports bet. I did an eight way parlay on NFL games that day. I bet on eight separate NFL games and they all had to win in a certain way. And I sat down to watch some football and write. And through the course of 12 hours of writing this memo about headless browsers, about the pain points, every single one of those football games won the way I thought it. I ended up winning that eight way parlay. And I think I just had a really good brain day. You know, the brain was really firing and 3000 words later I put out this piece of writing that really was some of the best writing I've ever done that was just so clear. And it was clear because I was writing about something I was passionate about, something I knew a lot about, I thought a lot about and it kind of connected with, you know, my career, which has been working for great infrastructure companies in different categories but also my passion which is, hey, I care a lot about headless browsers. I think it's just really kind of niche, interesting piece of technology that's under invested in. I think it just came together quite nicely in that one day and then I sent it off to some people and expected them to rip it apart and everyone said it was a great post. So I think that was the moment where I was trying to talk myself out of it in a way or just really more exploring what this thing could be. But it was cemented by the clarity of thought that came out of writing something you're passionate about that resulted in where Browserbase is today. And we've really followed that playbook from the memo from basically day one.

I love the eight way parlay win.

I'll have to send a screenshot. Yeah, it was a good it paid for dinner that night, that's for sure.

I remember, I think we met shortly after that and I think at the time it wasn't necessarily intuitive to me that the browser would be the primitive that AI would use to access the web. And I think a lot of folks philosophy at the time was oh, you know, the web will be reinvented for AI rather than AI getting better tools to access the web as it is. I'm curious, how did you gain conviction around the browser as primitive as opposed to a different type of interface?

Oh, it's certainly a contrarian bet and still is in some ways. We're doing the thing that might not be the most efficient solution, but it's one that works. Same thing is true with autonomous cars actually. We should rebuild all the roads so Waymo can drive much faster, but we're not going to do that. Roads are going to keep existing and Waymo is going to learn to navigate the roads as is alongside people. And I think you could apply that to headless browsers. I'm a lazy engineer. I think great engineers that we hire tend to be pretty lazy because they want to find the efficient solution to get the product solved. And I found it to be unrealistic that we would reinvent the Internet for AI. Now since then we've seen a lot of adoption of things like mcp which we did know that there'd be first party integration for the most high volume things. But if you're telling me that the DMV is going to launch an MCP server or some sort of AI native connector, I think we're still quite a ways away from, from that. And the rest of the Internet is still going to be needed to be used by people. And as long as people have to use the Internet, which is going to take decades for people to stop using the Internet as is, AI should be able to navigate it just alongside people in the same way they do. So that kind of like social change that's required to disrupt and remove the Internet. And browsing overall felt like that was so far away that there was an opportunity for us to build something great here. And Jeff Lawson, once again, big inspiration for me. When I asked him about Twilio, he said, well, when he pitched Twilio, people said, well, text messages is going to go away. You don't need text Messages. You have RCS or iMessage or any of these new protocols. He said, sure, it may eventually go away, but that's a very long bridge. And I think it's a great case study of sure, you can build a great infrastructure company around a technology that might not be around in 50 years, but man, if we can last for 50 years, that'd be a pretty great journey. And I think we'll be creating a lot of value along the way and continue to move up the stack into other adjacent areas of the agent runtime that are going to be helpful for our customers in additional ways. So the browser is a starting point. It's certainly not just the only destination, but it's a path on our journey to helping all developers build great software.

Yeah, and I think it goes back to something you said earlier around having 1,000 customers and being close to them and getting feedback, sort of solving the problem as it exists today gives you in many ways the right of first refusal to solve every incremental problem that developers have as they start to build more and more with AI.

Yeah, exactly. I mean, you can look at our product roadmap, but that's why we launched our browsing framework Stagehand. So we had the infrastructure first and then customers kind of came to us and said, hey, we're having a lot of trouble using an LLM to generate actions on the page. We wanted to click the button and it's not clicking the button. So we built Stagehand. It's an open source browser automation framework similar to existing frameworks Puppeteer, Playwright and Selenium. But what's special about Stagehand is that it not only will have the same interfaces where you can click a mouse and move the mouse and enter text, but you can give IT natural language, and it will convert that natural language into the appropriate browser command. We describe stachehand internally as the code interface for the browser and developers. The first developers using it were our customers who were having a lot of trouble actually using AI to automate the web. Stagehand made that easier and of course, it ran the browsers on Browser Base. So similar thinking here is how can we always move up the stack just a little bit and help make the adoption of browser automation within our customers, features and applications just much easier? That's really inspired our roadmap and I think we have a lot more stuff coming out to make that even easier.

Yeah, it's been amazing to see how you've gone from building Browser Base to building Stagehand and sort of collectively the enthusiasm in the market for it. Why do you decide to open source this technology and more broadly, I'm curious, how do you think about the layer of abstraction versus developer control as you move up the stack?

Yeah, open sourcing it was a really important decision, especially picking the license type too. We went with a very friendly MIT license. We could have done something much more copy left. And it's a bold choice. You have to be confident to release something you're going to invest a lot of time and money into in the open source domain. But the reason we did it was a few different reasons. First of all, we learned a lot from developers in the community when building Stagehand. There was technologies and ideas that we put into Stagehand that were inspired by other projects, especially the Playwright project. Right. So it felt important that if those projects were open source, Stagehand should be open source as well. It does. Right. By the developers who are inspiring us. Secondly, listen, we're still early days, we're 18 months old. We want to make sure that if someone is using Stagehand, if browserbase goes away as a company, they still have the opportunity to run this infrastructure, or run, sorry, run this framework, even if we're not around now, with this most recent fundraising round, we'll be around for a very long time, thankfully. So it's not as much of a concern. Yeah, knock on wood, of course. But with Stagehand, it gives champions of our product within larger enterprises a little bit more staying power, saying, listen, hey, we can always use our own headless browser infrastructure. Stagehand is open source. We can see how it works internally. Look inside the black box and it gives up a lot of confidence. And that's been really helpful for us as we get Stagehand more adopted. I think the MIT license makes it so anybody can adopt Stagehand at any sort of company. And your second question, which was about, like, how do we think about the, like the ergonomics of, you know, the right developer abstractions? Well, I've always said less is more. You know, stagehand really has three, you know, APIs. You can act, you can extract and you can observe act. You can say, click the button or click the button, extract. You can say, give me a list of all of the companies on this website in a table view. So data extraction, unstructured text extraction to structured and then observe is like, hey, can you help me to say, is this the pricing page? You're asking a question of the page. Turns out those three functions really do a lot for our developers. And when you're integrating in tools into an AI agent, if you expose many different functions for it to call, it's going to be less reliable. It's going to. It's kind of confusion when deciding which tool to call. When we give it three very clear, very specific tools, it actually ends up working much more nicely in AI agent workflows. So I think that's really pushed Stagehand forward. We've kept it simple and then people can just understand it more when they look at the source code.

Yeah. The decision to open source Stagehand and have it so naturally integrate with browser base really is reminiscent for us of what Vercel has done with Next js. And that's obviously been an incredibly powerful combination and it's been really exciting to see how quickly Stagehand is growing and kind of the traction you're seeing with developers. So on that vein, today you're launching a new product as well. Director. Director's super exciting. We want to hear about it. From my perspective, it feels like kind of the V0 in this. Right. Maybe.

Or a lovable or a bolt.

It gives the opportunity for someone in natural language to explain what they want and out comes a really satisfying experience. We've had a chance to play with it a bit and it's very powerful.

Tell us a little bit about Director.

Yes, I promise I'm not copying you, Guillermo. And everything you do. Right. There's some similar strategies here, but I think it's actually quite funny. When you start with infrastructure and frameworks, you tend to see the same lessons. There's analogies here, similar with API companies. Right. And for us, you know, we started with browser based, the browser infrastructure, the browsers running in the cloud that you can control. Then we launched stagehand, the framework for controlling browsers. It's a code interface for the browsers, it's how you actually tell the browser to do what needs to do. And Stagehand, it's an SDK, it's a framework, you still have to write code to use it. And what I saw when talking to customers, we had this period of time after our Series A announcement where there was a lot of like dentists and non technical folks who were coming into our support chat or booking calls with me and they'd say, hey Paul, listen, I know I look like a dentist, but I have cursor, I have Claude, and I'm writing software and I'm trying to use Stagehand to automate this back office thing that we're doing. I was like, wow, that's so cool. And it's still challenging, it is still challenging to build robust software, even with the latest and greatest in Vibe coding tools. But I really loved talking to these people because they had a challenge. They had a boring work task that they wanted to automate that they do every single week and they wanted AI to do it. And the difference between them using OpenAI's operator or some of these other kind of tools out there is that they wanted it done exactly in the same way each time. And for them, they wanted to build something more bespoke. In the age of Vibe coders, primitives are actually extremely important because Vibe coders are piecing together primitives to build bespoke software that's designed specifically for them. So Director, this new product we're launching today, Director AI what Director is It's a tool to allow anyone to generate web automation scripts using natural language in this kind of nice progressive way. You give it a task, hey, I want you to go grab the last batch of YC companies and it will go ahead and not only start to do that task, but along the way generate the code that you can take out and put anywhere else you want and run that task every single day for the next six weeks. It's taking this idea of like, we're not just building agents, we're building agents that output software that you can then take, customize and deploy anywhere you want. So we do think very similar to V0, where you're chatting with an agent and it's generating some software. In that case it's a front end website. In this case it's actually a lot more challenging because it's generating a web automation script that is quite progressive and linear. You know, to go back and say, oh, instead of yc, do Neo instead, now it has to regenerate a completely new script. Right. So it's still. It's a very challenging problem, but we found that it's a great experience for people who want to automate something they have a problem they want to solve. But Director is kind of the first stepping stone for you to then discover statechanned and then discover Browser Base. And we think it's going to be a great prototyping engine. We want to arm the PMs and the CEOs and the head of operations who may feel like, why aren't they getting all the cool AI tools? You know, why aren't they getting something to help them make their work more efficient or more productive? Having them start with Director, get something prototyped and say, look, it does this most of the way. Can we get this into our application somehow? Can we make this a feature and then handing that code that's created off to an engineer to go productionize it? I think that's a really tight feedback loop and we're frankly excited to use that browser base for demos, you know, on every call. The way we're going to start a call is like, well, what are you trying to automate? What's your problem you're trying to solve? Well, let's try and build that together. And it's made the process of showing what browser Base can do for our prospective customers just a much tighter feedback loop. And then they get to walk away with a script. It's great to walk away from a call with a piece of software at the end of it. Normally you're walking with a pricing sheet. We're trying to give you your POC ready to go, so you can get building.

You've had people playing with Director for a while now in some sort of closed beta version. Any interesting use cases that you've seen people working with that have surprised you?

Yeah, I think, once again, the vastness of these cases is very surprising. One of our use cases we had was ordering a set of screws from McMaster Carr, a big supplier website, and making sure those screws can get here by a certain date. And that requires a lot of different workflows. First you have to go to the website, you have to find the appropriate screw. You have to parse these complex like, okay, one order of this contains 1,000 screws. If I need 100 screws, what do I do? I'll have to order the thousand. Adding it to cart and then extracting data out of the CART page to see the estimated shipping date. It's not just web scraping, it's actually a complex browser automation workflow that each step has impact on the next step and it needs to go off without a hitch in the end. People always say, well, what are you excited to see people build with browser base? I love the boring stuff, I love the unloved things. I love ordering lumber in Mexico or trying to find every 711 in a part of Japan. Like that's the stuff that I think is very, very interesting to me. The flight booking and the restaurant reservations is a common use case that people think about, but that's actually really not the best use case of browserbase. It's the things that aren't loved, the things that are low volume and long tail. Those are the ones we want people to try and build with Director because that's where you're really going to see a lot of success and can build something that might not be a first party integration on day one.

I think another trend that we're seeing is that the best developer tools companies are both very functional and also fairly opinionated. And I think that's appealed with both developers and with sort of LLMs that are increasingly writing code on behalf of developers in these sorts of vibe coding tools. I'm curious, how do you think about how opinionated the developer experience should be and how to appeal to both the developer and ensuring that you become kind of that default that the LLMs and the agents of the future use in order to automate the web?

Yeah, I mean there's a very fine line between something like Vercel and aws. Right. And you can see what happens when you have maybe too much surface area and you're unopinionated. You try and capture everything for browser based, you know, I always like to think about abstraction as, you know, these kind of escape hatches where the paved path experience should be very simple and get you running. But if you do need more configurability or customization, you can then open the escape hatch into something else. And maybe that's why with Director it's the most simple poc, it's really easy to get started. With stagehand you get more customization and with browser based you really are touching the browser itself. Right. Simplicity is king for helping people understand a new concept. This is a new category we're talking about. People are familiar with databases or familiar with hosting. Most developers are actually quite unfamiliar with headless browsers. So it's on us to take this complex piece of infrastructure, distill it down to its most core elements and make it easy for everyone to understand so they can feel like they Understand what they're building on. It's very important for developers to understand the primitives they're working with. And we try and package up the essence of headless browsers into something that's easier, easily digestible, so that every engineer can integrate this functionality when needed into their product.

Paul, you talked earlier about this long transition. The Internet was built for people. Now agents are increasingly trafficking the Internet. But websites are, while some are probably faster to adopt an agentic user base, others are going to take longer. How do you see like just look into your crystal ball for us, like how does that world evolve over time? Will we have sort of two Internets that get created or do you see like a merging of these two over time or just a coexistence? What should we expect to see? Given your vantage point, you're in a really good spot to answer this.

Yeah, you know what we imagine happening is that for use cases where companies want to have more control over how agents interact with their application, the path forward is actually establishing some integration point, probably an MCP server or an API that's publicly available or a set of agent tools that are available within every framework that will be popular. For companies that have a lot of volume, a lot of agents using it, there should be freeways or highways to accessing those applications. Now for the rest of the Internet, the 99% of the rest of the Internet, I imagine that it won't change very much. You know, most websites that are out there, they're going to stick around. There's still a lot of COBOL out there right there. There's still a lot of asp.net or WordPress. WordPress takes is like most of the Internet actually in volume of websites. Those aren't going to get updated. And if your AI agent has to go to a website that a user tells it to and it doesn't have a first party integration, you're going to need a browser. The browser is the primitive. And it may be a primitive of last resort in some cases, but a necessary primitive for your agent to go, you know, work with every task a user can ask of it. And that's a really important part. This is a new type of software where when you use your using software, you can tell it to do anything. You can say, hey, I want to get a research report on this company website. And if they don't have an MCP server or an API, how are you going to do that? Well, you have to go look at the website itself itself. So we think that in every agent the browser is one of those, you know, horizontal primitives that needs to be added so an agent can fall back on it when needed. But I think a lot of the web is not going to move to a first party integration with AI anytime soon. We would have to rebuild a lot of the Internet for that.

So we're going to be in a, in a world where it sounds like it's, it's like a layer of the onion, like it's not going to fundamentally change, but you'll see more newer technologies, newer infrastructure get built to satisfy the needs of both human and agent over time.

How many websites have a mobile app is a great example of this, right? I think you may invest in a mobile app or mobile application for your company and your website if needed, if that's the path you want to put people down. But many, many websites don't have a mobile presence or mobile app that you install. I think it's quite similar here. If companies want to invest the R and D and the capital to maybe build a first party integration, they can and they might. But if models keep getting better and faster and cheaper, do we need those pathways or can they just browse the web like we're going to have to for a long time? My parents and my grandparents are going to keep doing Google searches on google.com for the next 10 to 15 years. So I don't think that experience and browsing the way we have it right now is going to go away for quite some time.

You had a chance to work closely with Jeff Lawson. Obviously he's an incredible founder and Twilio under his stewardship was a remarkable rocket ship of a ride. What'd you learn from Jeff?

Yeah, there's a ton of stuff. I think developer experience is paramount. And if you look at Twilio's early days, it was best in class, in developer experience. And Jeff always had this thing about like the five minute demo where when you're demoing Twilio, someone should understand Twilio within five minutes. And the moment of magic was you'd send an API request and your phone would light up. You know, with browser based, we think that's even faster in our playground. You click a button, you run a script and you can see the browser, the mouse is moving and it's like, whoa, the computer's controlling my browser. That's very cool. So you need to have a really tight moment of magic, which is often quite challenging and in infrastructure. And Jeff made that very clear at Twilio. And finally, and probably most importantly, Internal and external messaging is one of the most important things a founder can do. And on the internal side, the Twilio All Hands experience was so foundational for me in learning how to build a great developer tools and infrastructure company. You know, I learned about NRR and net dollar retention and cohorting revenue and about pricing and how unit economics really played an important part. And what was great is because it became a public company and we still did the all hands I had, I got to see the results of that on my earnings through RSU's but also the public markets and their reaction to hey, we have a bucketed revenue with one large customer. And I think those like I got my MBA in the Twilio all hands I would say. And Lee Kilpatrick is an amazing CFO there who put a lot of time in George Hu as well. Great leadership team who really made sure to not only just execute on building a great company, but teach everyone how we're doing it and why we're doing it that way. And I try and carry that back to the browser based All Hands and really try and spend a lot of time on not just the things we're doing, but why we're doing them and what the output is on our business and how it makes us a little bit better.

If you look into the future, not a thousand customers, but maybe many times that, what does the future look like for Browserbase if you, you know, in your crystal ball, that five year view, what, where do you want to be?

Yeah, I want browser base to be the default way that every AI company interacts with the Internet. And I really want us to establish ourselves as the primitive that everybody is pulling in to this future of software. And that's going to mean our browser infrastructure, our framework, our products to make adoption better, the ancillary features we're launching to make everything easier when you're browsing the web, that's going to be that default choice developers make. And hopefully it's like buying. People always say when you buy Oracle, you're buying Oracle because you'd be crazy not to. I want that to be the same choice people are making with Browserbase. And we still have a long way to go to earn that right. But hopefully many years from now, the first thing you do when you build your agent is you're going to pick your model and then you're going to pick browser base.

Super compelling vision. I can say that on behalf of Dan, myself, our entire notable team, we're incredibly excited Today's news. Joining you officially as your lead of your Series B. We couldn't be more excited for that future and we look forward to going on the journey with you.

Thanks guys. Excited to go build it.

Thanks for joining.

Thanks thanks so much for listening to.

Another episode of Founder Real Talk. We really hope you enjoyed it. If you like what you heard, please rate and review us on your podcast app to help others find this podcast. If you have any questions you'd like to ask our guests or founders you'd.

To like like to hear on this.

Podcast, feel free to email us@frtotablecap.com notable capital is a global venture capital firm based in the US Focused on early to growth stage companies in business and consumer applications and cloud infrastructure which includes AI, cybersecurity, data, DevOps and more. The firm has offices in Silicon Valley, San Francisco and New York. We invest primarily in the US, Israel.

Europe and Latin America.

Notable capital's enterprise portfolio includes companies such as BitSight, Block D Scope, Drata, Hashicorp, Monte Carlo, Neon, Nozomi Networks, Orca Security, Slack, Synack, Vercel, Zendesk and many more. Learn more@notablecap.com or follow us at on X and LinkedIn at.

Notable Capital this episode was produced by Sashi Productions Music produced by Gus Culpo. The opinions expressed in this podcast are those of the individuals only and do not reflect the views of their respective employers or affiliates. The information provided is for informational purposes only and should not be considered or deemed to be as investment advice in any way. Thanks again for tuning in.