软件超新星：Bolt.new——浏览器里的 AI Web 应用开发者

The numbers we've publicly disclosed: in the first 8 weeks, we went from $0 to $20 million in ARR, and we've just continued to grow since then. We actually wrote an operating system that runs natively inside your browser and boots in about 100 milliseconds. There's 0 latency; there are no cloud VMs that have to be spun up. It gives you a very reliable experience that can actually scale.

If you force people to download something to their computer and set it all up before they can use it, the drop-off is insane. It's like 90%, if not more. Whereas when it's native in the browser, it's frictionless, and then the actual AI augmentation picks up from there. It's an order of magnitude more complex to set up an environment locally for any of these things.

You guys have made a splash, to say the least, in one of the hottest categories going right now, which is the full-stack AI software engineer. People are prompting their way to all sorts of creations on your product, and the revenue is popping off. You guys have raised a bunch of money. We're going to get into all of that.

For starters, I would love to get a general sense of your AI worldview, because I feel like so many of these conversations are much more intelligible, and the details are much easier to understand, when you have the person's big picture in mind. How would you describe where we are right now in the AI moment? What is your expectation for AGI or transformative AI? Are you somebody who worries about risk? Do you maintain a p(doom)? Give me the Eric Simons AI worldview in a minute.

To me, what's been very interesting is, if you rewind a couple of years to when ChatGPT came out, the first year after that, people were like, "AGI is going to be here within a year." There was a lot of hype, and understandably so, because it was obviously a pretty big zero-to-one moment. These models have gotten really good at certain things, but software is one area where it makes sense that it's getting a lot faster, because code is text-based and it's easy to train things.

Also, code is deterministic. If you want to train an LLM to be good at law, you're looking at cases dating back to the 1700s and how a judge felt at the time. That's not deterministic. But with code, you can write code, AI can write code, and you can evaluate it: Did it do the thing or not? Then that's a new test case. So it makes sense that, in the past year, that's where some of the biggest leaps have happened, and that's going to continue.

My pragmatic AI worldview is just that the world of software is getting rewritten. I think software is actually going to be maybe the first major tectonic shift, where stuff is just getting replaced by being generated anew. I think that's going to be huge, because the bar is going to be lowered for creating software. To me, that's the most interesting, very tangible thing that's happening right now, versus the question of where things will be a year from now or 5 years from now. I like to take the pragmatic, on-the-ground view of what we actually see moving in a meaningful way.

Obviously, the stuff around reasoning is a pretty big breakthrough, I would say. But again, the question is, where is it going to be a multiplier? Particularly, applying reasoning to software development—boom, that's huge.

Holistically, I think it's just going to be a good thing. I don't think this is going to be like every other technology that's come before it. It tends to be a great enabler of a different future. Things are reconfigured differently, but it doesn't strike me that what I see now is just people who couldn't code before being able to build real production products with software, and engineers who are fantastic today being able to leverage themselves 5 or 10x. The world needs more software; we've just been constrained.

Yeah, it's been pretty much universal, I would say, among businesses that create software at all that, if you had asked at any point in time—and still today—"Is there more you would like to be creating if you could?" they're all like, "Yeah, we're totally constrained by how many developers we have." We're constantly making these trade-offs, constantly prioritizing. I've certainly lived that life myself.

Your comments about reasoning are interesting. Obviously, we're in the o1-to-o3 transition period, and then there's also the R1 moment. It is crazy to think that we haven't seen it as the public yet, but the o3 results, where they have the model in the top 200 coders in the world on competitive coding challenges, are really a pretty crazy result. That's like beating almost everybody at OpenAI. I think they thought there was maybe 1 person left at OpenAI who has a higher score in competitive coding challenges than the latest model does, which is pretty wild to think about.

How do you think we'll be interacting with software? What might the software landscape look like in the future? I'm a big believer in "we need more software," but I've also started to believe in the concept of luxury software. I just saw the phrase "selfish software" for the first time yesterday, and those are kind of similar ideas.

Basically, potentially you don't need to create software for a mass market. Potentially, you can just create for yourself or for your team, or you can create AI apps that spend an unreasonable amount of tokens because it's worth it to you, even if you couldn't necessarily take them to market in a scalable way.

I would love to hear what your vision is in terms of how you think we'll be interacting with software and what the software landscape might look like in the future. I do also feel a tension where, to some degree, yes, I want these personal things that are made exactly for what I want. Then I also think, "But I really want to use well-polished stuff with good UIs." In today's world, it's easy to have that vision, but it's also easy to get to a point where you're like, "I tried making this thing for myself, but it has a lot of bugs, and it actually is not exactly living the dream yet." So give me a little more color on what the future of software development and user experience might be.

It's a good point. If I had to rephrase it, you're pointing out that there's kind of a long tail. You can have this thing punch out software, but there's a long tail of UX and even just support issues that are not addressed. Even if you look forward, it's like, okay, if you're constantly having to use what, at least today, are expensive models—and maybe that price is just going to keep going down—it's really a question of how far out into the future the long tail is dealt with. Where does equilibrium hit, basically?

I think you've kind of hit the nail on the head. For certain use cases today, it already makes sense. People who are using Bolt are building internal tools for their company that are actually relied upon for critical business functions, or whatever. People are building real products that are their startups and that sort of thing. In both of those cases, you're dealing with people who have a keen eye for product.

I think the people who find the most success with Bolt—and I imagine other tools in a similar space—tend to be PMs and designers, and of course engineers. But I'm going to put engineers to the side because they know how to write software. The people who don't know how to code—entrepreneurs and PMs—know how to build great products. They know what that experience looks like and feels like. They know how to sculpt the thing, and previously they could only write that code through someone else's fingertips.

Again, for PMs, their job is really interfacing with developers and helping point them in the right direction to actually make the product experience great. Now, with AI, they're just saying basically the same words and getting an instant result: "No, no, no, more of this, less of that," or whatever. I think for folks who fit that category, they're already finding a lot of success today.

Over the next year or 2, it's going to be even more. When you get to the general end user, I think the point is extremely valid. To reasonably expect someone who has not been in the business of building products to really be able to build something that's going to be bug-free and a great experience, I think there's going to need to be more, in short, under the hood: just more inference and more capabilities in these models and in the agents to actually allow you to do that.

Right now, it's very rudimentary. A lot of the issues that people run into when they use Cursor or any other tool, when they're nontechnical, come down to this: when stuff goes wrong, how do you fix it? So that's certainly trending that way. I think a lot of the folks in that category—PMs, entrepreneurs, designers, et cetera—will be the first big market unlock here. It's already happening: these folks are coming online and writing software, and in the next few years that's going to explode.

That's quite interesting and sort of anticipates another question I had in terms of who your target customers are today. It sounds like they are people who are gaining leverage and doing things they probably otherwise just would never see bubble up to the top of their to-do list, because they can now talk to a product like Bolt instead of having to talk to a human. Obviously, the cost ratio there is massive.

Yeah, our user base: we see something like 40% developers. 30% to 40% are traditional software developers, and 60% to 70% are folks like PMs and entrepreneurs, that sort of category. They're not software developers.

In the developer category, this is a 10x multiplier on their ability to go and make prototypes, ship UI, or whatever have you. They're coming to us to drop in stuff from Figma or prototype an app they've been thinking about, and instead of going and writing out a whole bunch of code or having to instrument stuff in Cursor or whatever, they just come to Bolt.new.

Then they drop it in, hit Enter, put in a couple of prompts, get something great, pull it out to GitHub or locally or whatever, and then continue building on it. So that’s a very concrete use case. That’s one of the ROI stories. There’s this guy, CJ, on Twitter—I don’t know what his handle is—but he’s got the most insane ROI that I’ve seen.

Basically, he’s a freelancer, and his client had him build a web app, some dashboard or something. He spent, I think, $7 worth of inference on us. Someone asked the question I would have asked, had they not, which was, “How much did you bill the client?” The answer was $9,000.

If you go to Twitter and search “Bolt arbitrage,” there are a lot of developers and freelancers connecting the dots here, because the demand-supply curve has not begun to normalize on that yet. So that’s kind of that one category. We have Fortune 500 companies using it to prototype instead of using Figma and that sort of thing.

On the PMs-and-entrepreneurs side, whether it’s a side project they want to launch, a startup, or a side business, folks are using Bolt to build full-stack applications with payments, authentication, databases, and all that sort of stuff. Even if they’re at a company, if you think about the role of a PM, a lot of their job is writing Jira tickets, explaining how to make the product better, assigning it to someone who’s going to code it, having them say they did it, and then reviewing the work and providing feedback.

Wouldn’t it be great if, instead of writing the Jira ticket, they could just tell an AI to do it, get immediate feedback, and, when it looks good, just commit it? The developer can pull it down, and they have no idea whether it was written by a coworker or an AI. It doesn’t matter.

We’re seeing that use case a lot as well, both for people who are starting their own projects or startups and for businesses that are starting to come online. It’s like, “Oh, okay, this is a huge multiplier.” For the developers, it’s a better use of their time to work on really tough functionality that the AI models are not great at, at least zero-shot, and the PMs can go ahead and create the level of UX polish you’re describing: make the buttons align, make the colors right, and make sure that this goes to that page when you click it—simple stuff like that.

They can just do it, make sure it’s perfect, and then ship it. So those are the 2 segments of the audience we see and the use cases where they’re finding a lot of success.

Yeah, that’s interesting. If I imagine not too long into the future, it seems like everybody has this vision—and it seems like from your answer we’re not quite there yet—where people who have not been in the product-creation business at all could start to get into the game.

I imagine a number of different stumbling points or barriers that they would have to get over. Some of them would apply even to today’s users—the PMs and even the developers—but others would be easier for your current user profile and harder for people like my dad or my mom, who have never done anything like this. My dad has plenty of ideas, so maybe we can run through a few and you can tell me how you’re thinking about them.

One is just drawing out of people what it is that they want. I think when my dad sits down at something like this, he’s greatly underspecified in this area, and then he gets something back from the product where he’s like, “That’s not what I wanted.” I wonder to what degree there’s a way to get over that.

I would also flag, as you did, when things are not working, how do you fix them? That has probably been one of the trickiest pain points. I’m really interested to hear how you’re addressing that and what you think the trajectory is there.

Another one is deployment, and that’s also, I’m sure, a really critical one for your business, because I’ve lived this reality too at times. It’s one thing if people can come in, make something with your product, export it, and never have to come back. It’s another thing if you become part of how they actually operate their business, so I’m sure that’s something you think about a lot.

Deployment is definitely a major pain point. You might also have your own taxonomy of other challenges, but sound off on those 3 at least.

So, on the first one—people who have not worked as entrepreneurs or product folks before, et cetera—we have folks who are coming to the product and to us who don’t fit those categories exactly. Everyone has to learn how to build great products. There’s a general skill of learning how to really sculpt something.

What’s cool about Bolt—and, again, just these AI generative tools—is that it’s lowering the barrier to entry to come and learn how to actually build great stuff. My co-founder and I grew up down the street from each other in Chicago. When we were 13, we learned how to code together, and we learned how to code together because we wanted to build products. That was the reason we got into building software.

If this had existed then, I don’t know how deep we would have necessarily had to go, or have gone, on becoming software engineers, because our end goal is to build great products. I think we have a ton of people coming to Bolt today, and they’re learning by actually working with the AI how to best leverage it to build products and picking up the general how-do-I-build-products or how-do-I-build-a-business skill set.

It’s funny: a couple of weeks before we launched, I had my mom, who’s 73, test this thing out because she’s the—I love her, she would admit this readily—probably the least technical person you’ll ever meet. She built and deployed her first website on this thing without any guidance because it’s the simplest interface in the world. It’s a text box: you type in what you want, hit Enter, and then there’s a deploy button where you get a live URL. That’s it.

There are a lot of use cases, too, that we’ve seen of people building this for personal use and for weddings. One guy tweeted us that his daughter needed medical donations or something like that, and he created a website to do that. To me, that was touching, but I was also like, “Should I tell this guy that Wix exists? Squarespace?” We’re not the first people that have allowed you to build a website.

But then it hit me: for my wedding website in 2021, I used Squarespace because my wife and I had originally wanted to build the site ourselves. I spent a day one weekend on it and never came back to it because it takes a lot longer than you want. So she made me use Squarespace.

The interfaces for those things suck. These drag-and-drop builders are really complicated to use, and they’re supposed to be targeting less sophisticated computer users than me. But when you look at Bolt, this is it. It’s a text box. That entire category is going to go away. There’s no reason for drag-and-drop builders when you have this sort of stuff.

On how you educate these folks and make them successful, I think there are 2 direct ways that you can do that, and then there’s a rising-tide thing that’s going on. One is education: instead of just the school of hard knocks, where people prompt the AI and figure it out, create great resources.

I think this is one of the things that’s been very effective for us. We’ve invested a lot in our community because, if you look at Midjourney, it’s probably one of the best examples. What made Midjourney really successful was the community of people prompting and then sharing those prompts, et cetera.

That’s kind of the same thing we’ve got with Bolt, where we have a very vibrant community of folks who are sharing how they’re doing it. We’re learning a ton from these people because they’ve used the product more than our own core team has at this point. They’re the domain experts on the thing.

We invest a lot in our community, our educational resources, and that sort of thing. That’s a long-running way to ramp people up.

The second thing is that we’re not at a point—tangibly, depending on whether you’re trying to build something pretty complex—where you can actually, without any technical knowledge, just rely on AI to get all the way there. Really, what you need is someone like me who’s reasonably technical, or is just very good at debugging these things, to grab 30 minutes of their time, plug them into your codebase, and get them moving.

We haven’t announced it—I think we’re announcing it next week. I don’t know when this is coming out, but if this scoops our announcement, I guess it was heard here first. We’re actually rolling out a program where, within Bolt, you can raise your hand and go, “Hey, I’m stuck on something,” and we can connect you with an expert we’ve certified who can punch in, help you get debugged quickly, and get you back on your way.

It’s basically a way to get quick, on-demand help to get unblocked or get a professional opinion on something, and then move on. I’m not aware of anyone else who’s done that model really well, so I think we’ll probably be one of the first. The third thing is that these models just keep getting better, and we’re making the agent better and better, et cetera.

The quality of the models is just a multiplier on everything that’s leading up to that: how much you have to learn and how many times you need to loop a human into the process to help debug you. If you look forward over the next 6, 12, or 24 months, the better those get, the less you’re going to have to rely on the other things to actually keep proceeding.

But even today, we’ve crossed this chasm where it’s crazy valuable. That wasn’t true a year ago.

Yeah, I think we’ve officially put to bed the “no progress since GPT-4” narrative that popped up for a little while there. Even before the o1 series, I was like, “Guys, there’s been a lot of progress on just making GPT-4-class models do the things that we actually want them to do in a much more consistently useful way.”

So I totally agree that the progress has been pretty amazing, especially in areas like code. The human-in-the-loop thing is really interesting.

You guys are literally exploding right now. I don’t know what metrics you’re tracking or how much time you even have to stay up to date on metrics, but do you have a sense of what your success rate is if somebody sits down at the product and says, “I want to build X”? How often do they actually get to X versus getting stuck somewhere they can’t get out of?

Do you also have a sense of what has moved the needle on that success? I assume getting the model to do a better job is core to that, but I’m wondering: are you fine-tuning? You did mention choosing integrations. That’s another thing that I think people are very overwhelmed by by default: “Oh my God, I want to do payments, but what do I use?”

It seems like you’re being pretty prescriptive, sort of, “This is the happy path that we think you should go.” I imagine that’s been a driver of the success rate, but what is the success rate? What’s driving the success rate, and what do you think will drive it in the future?

Yeah, good question. I think we’re seeing a good success rate. At a high level, you measure this with revenue growth, and for us, with the numbers we publicly disclosed, in the first 8 weeks we went from $0 to $20 million of ARR, and we’ve just continued to grow since then. We haven’t seen the ARR go down at all.

When you dig into the usage metrics as well, we’re seeing more and more folks coming to the platform, and the retention is extremely good. With a lot of these products in the AI direct-to-consumer space, the churn on these things can be insane. They can be 60% or 70%. We’re nowhere close to that.

I think the acceptable range is anywhere from 20% to 50%. We’re hanging out in the 25% range, which is pretty good. People are finding a lot of success in the product and finding a lot of value in it because they’re sticking around, coming back every day, et cetera.

You can kind of look this stuff up online, but as far as AI code products globally, if you exclude Microsoft, GitHub, and so on, and look at the startups, I think free markets are a good way to measure how much value is being generated. For folks in startups, Cursor is number 1 at $100 million, we’re number 2, and then there’s a whole category of folks that are anywhere from, like, $5 million to $15 million ARR or something like that.

There are really only 2 tools at this point that have broken out from the rest of the pack, and that’s us and Cursor. I’m sure there are going to be other folks that pop out and that sort of thing, but I look at that and it’s like, clearly something here is working.

For our product, a lot of this comes down to the technology we made that enables this experience. I can show it in a second, but basically, if you think about, “Okay, well, if I’m going to come to Bolt.new and I'm going to type in words and get a full-stack web application back. That sounds great, right? But when you actually go to build these products, the question is: Where are you actually running the development environment for that? Where is that full-stack app running that the AI is programming? How do you do that?

This is just what our company has been working on for the past 7 years. We started out as a web-based IDE. The traditional way that you solve this problem is you put it on a cloud—everyone gets their own cloud VM using the service, et cetera. That's kind of been the model of cloud IDEs since Cloud9 was the first.

There's never been a breakthrough application that's been used by a lot of people that has this model where every user gets a VM, for a couple of reasons. One, the experience tends not to be great because you have latency. Every keystroke you're putting in has to be synced to a server, and the result has to be synced back to you. Someone's got to pick up the cost of that cloud VM because these things cost money. If you want to scale to 1 billion people, that's 1 billion VMs. It's a good amount of capital.

But the other problem is that there aren't 1 billion VMs you can rent on the planet. There are 1 billion devices—1 billion laptops, iPads, whatever. If you look at how Google Docs and Figma work, they don't spin up a cloud VM for each user to render your designs. As you're typing in the document, your keystrokes show up immediately, and that's because it's using your CPU, memory, and GPU through the browser as the interface to those parts of your device.

What our company did is we actually wrote an operating system that runs natively inside your browser and boots in about 100 milliseconds. There's zero latency, no cloud VMs have to be spun up, and it gives you a very reliable experience that can actually scale. When you look at the other approaches in the space, a lot of the issues folks will run into are that the cloud VM gets borked, it's extremely slow, and there's latency. There are tons of issues that can happen with these things because running in the cloud tends to be a lot more expensive.

Whereas with Bolt, within 100 milliseconds you have a live environment. The AI is just punching code into it, and you see the result instantly. I think that's something under the hood that's maybe not obvious to folks who are visiting, but from a technical perspective, that's the crown jewel of our company. We spent 5 years building WebContainers, this technology, and it just so happened that what we've been building with frontier AI makes this magic experience that isn't possible with any other approach.

I think that, in a nutshell, is the key enabler for us. Beyond that, we're certainly doing a lot around our AI agent. A couple of folks on our team who actually built the WebContainers technology had previously been working in ML and AI, so when it came time to write our AI agent, they knew exactly what to do to build it and instrument it so we can leverage the data and insights to fine-tune it and make it really reliable. We don't want to run into tons of errors for the end user because, again, we want it to be a smooth experience.

So, in general, there's kind of a lot there, but I think that's the 360 of why the experience is so different and why Bolt has had a completely different trajectory compared to the other stuff that existed before us and after us.

I've lived, for what it's worth, a pretty similar story. At my company, Waymark, we do video creation for small businesses. We've been on this journey—I call it “from DIY to done for you by AI”—over the last few years.

It was a similar thing where we spent a few years building an in-browser rendering engine for videos. Because we had a couple of major early partnerships, and one in particular with a cable company, Spectrum Reach, we had to deliver TV-quality specs. We couldn't take any shortcuts on the final thing. It had to be 30 frames per second and HD, and so on and so forth. It was a little bit crazy to try to do that in the browser, and we ended up putting a lot of work into that tech stack.

We had an in-between moment where we were like, “Okay, this thing is working pretty well.” But we found that people who were professional video creators still wanted to use the professional tools. People who weren't professional video creators were giving us feedback like, “Yeah, this is great. It's easy to use.” We were like, “So why don't you use it more?” And they were like, “I don't really know. I don't really have any ideas for videos. Or I did have an idea, but I sat down to try to write it and I got frustrated.”

We asked, “Could we make it—could we improve the product?” A lot of them were like, “Not really. It's just on me. It is what it is.” The AI thing totally changed that. Accessibility in a web-browser-based sense did not automatically translate for us to actual end-user value, but layering on the AI totally transformed that.

We haven't grown as fast as you've grown, but it has definitely changed the trajectory for us, too.

Yeah, I imagine. I mean, that's the exact same story. If you rewind 6 months, we had this awesome technology that developers loved, but we couldn't get them to leave their local tools and therefore build a meaningful revenue-generating business out of the thing.

We were looking at it like, “Okay, we might need to start figuring out how to wind this thing down.” At some point, after 7 years, this is cool technology, but we're a venture-backed company. This has to make sense, right? What you just said is exactly what happened with us. Hearing that it's happened with you—I remember you mentioned this when we chatted a couple of weeks ago—it makes me think there's going to be more of this.

If you think about people who are nontechnical, and you look at any profession, most professional tools, if you're going to be using a computer to do it, are local, right? Video editing and graphics editing were local until Figma, right? And Canva, I should say, too, for that matter. Development, video editing, video games—there's kind of this list of things that haven't come to the browser yet because it's just really tough to get professionals out of the existing environments that they're in.

Figma and the G Suite are kind of the only ones that have really broken through. But with AI actually lowering the barrier to entry, I think this stuff being able to live in the browser is a key part. The hardest part, if you want to become a software engineer—and this is the key insight that we had when we started StackBlitz, the company that builds Bolt—is that setting up development environments has always been the worst part.

From when we were 13 and learning how to code, it's like you're not even learning how to code. Week 1 and 2 are learning how to get stuff installed on your computer and just get a development server running, right? You're not even coding; you're just poking and prodding your machine to get it to work. This happens when you join Meta or Netflix, too. The first month is onboarding just to run the stuff on your computer. It's crazy.

If the experience of your product as a video-editing tool forces people to download something to their computer and set all that up, and then they get to use it, the drop-off is insane, right? It's 90% or something, if not more. Whereas when it's native in the browser, it's frictionless. Then the actual AI augmentation picks up from there.

There's an order of magnitude more complexity to set up an environment locally for any of these things, and then there's an order of magnitude on top of that to actually know how to code or operate these things. If you can collapse that stack, it seems like there's probably a good number of plays that could be run here. People who have been building things to be browser-native, by integrating really great agentic experiences into them, can open up to a totally new market of people who will find value in it.

Even for the professionals, they're like, “Oh, wow, this is great. I can just punch in here, tell it to make me a video, or make me a full-stack web app that I scaffold out, and then I'll pull it down locally.” It's still valuable, but it just blows the lid off what you can do.

Yeah, it really helps that the model is incredible for sharing as well. The amount of times in the past where I've experienced, “Okay, it's done, but where can I use it?” is just an absolute nightmare. It's like, “Well, it's on my local computer.” “Okay, but how do I use it?” “Well, I've got to deploy to staging.” Oh, God. I've felt that pain.

Do you want to do a little demo?

Sure. I was just thinking maybe I can show you how the thing works real quick. I'm going to pull this up. If you go to Bolt dot new—

Bolt.new, which I love as a domain. It’s just the simplest thing to remember. You go to bolt.new, and we’ve got a free tier. One of the cool things is that this is probably one of the best tools in the world for actually building beautiful-looking user interfaces.

Hopefully, the demo gods play nice up here, but we can just punch in anything that we would want to make. If I say, “Make me a music app that looks like Spotify,” let’s just go ahead and enter this. This is a pretty unbounded request I’m giving this thing, right? What you see here kind of looks like ChatGPT or something like that until this happens.

On the right, this is what I was talking about with the core technology we’ve been building. This is actually running a full operating system inside my browser. It’s already booted, and it’s already installed the dependencies for this project. Right now, the AI is just writing out the code for this thing.

I can type in commands like I would on a Unix-compliant operating system. For those who are developers, we’ve built this in WebAssembly and booted it inside the browser.

You made your own from the ground up? It’s not derived from anything like that?

No, we had to write it from the ground up. The reason being, if you want it to be fast—if you want it to boot in 100 milliseconds—there are things that will let you take a Docker image and convert it to Wasm or whatever, but the image, the Wasm file, ends up being 100 megabytes or more. It runs 10 times slower.

What’s Wasm, I guess? How much do browsers anticipate this, or how much are they built to enable it? I know the video story of this. In our case, there’s WebGL you can use. It’s not necessarily meant to do 30 frames a second, but it can do stuff. What was that like, creating a WebContainer experience?

Hard. The thing with browsers is that they’re very strange with what APIs they provide. As you know from building on these things, they’re not the sort of really robust interfaces you typically get on your own computer if you were to build software there. This is why you don’t see a lot of these productivity tools come to the web, because if you want to do it right, you have to start from scratch.

This is the same story as what happened with Figma. Back in 2012, my co-founder and I had the good fortune of bumping into Dylan and becoming friends with him when he and Evan were starting Figma.

Their first pitch for Figma was not a design tool. They were like, “Hey, we want to build a design tool, but what we have today is just this 3D ball dropping into water.” Let me see if I can actually find that. It’s kind of an iconic Figma 3D ball demo.

So this is the demo. Evan Wallace, a co-founder of Figma, made this demo of a 3D ball dropping into 3D water so you can see the actual ripples, right? This was back in 2012. It was a game changer because you couldn’t do this in browsers before, but WebGL had just landed in browsers. WebAssembly—or its predecessor, asm.js—had just landed in browsers, and that’s what made this possible.

Their pitch was, “Design could not have come to the browser before, but now it can, because look at what you can do.” We can certainly build a 2D rendering engine around WebGL and WebAssembly, but we have to write it from scratch on top of these specific technologies. That’s what they spent the first year or two doing: just building a rendering engine that the Figma product could actually be built around.

For us, it was the same deal when we went to build WebContainer. When we go to the code view here, this terminal is deceptively simple. What you’re looking at here is deceptively simple, but we had to write something from scratch because if you want people to expect a web page to load in 1 second, the size of this operating system is going to have to be about 2 megabytes, maybe 1 megabyte, and it’ll need to boot in about 100 milliseconds.

That is what we built here, completely from the ground up, and it took us years. We’ve been working on this thing for about 5 years at this point. It’ll be 6 this year, but it’s a classic deep-technology play that enables this to boot so fast.

If I hit refresh, let’s say there’s something wrong with this. Imagine if Gmail breaks—how do you fix it? You hit the refresh button, right? That’s, again, the benefit of taking this sort of approach. If there was something wrong with that operating system, it just booted a brand-new, fresh one, installed the dependencies, spun up the server, and, boom, we’re going to see the application in a second here that we just built.

If you compare this to anything else in the space, you’re getting connected to a cloud VM, so there’s a lot of latency. If the thing gets broken, you have to contact support and hope that they have good support.

That is fascinating. Now that we’re here and we’ve got this thing generated, first of all, did it just generate these images on the fly as well, or are you including them?

Yeah, it’s smart. It’ll go grab images that it thinks are going to be relevant for you. These are the ones it pulled to go with.

These are the real album covers, are they?

No, I don’t think so. Everything that we’re pulling is royalty-free, or whatever the applicable license is. It goes and grabs good placeholders. You can tell it to use other stuff if you want, but this is zero-shot. All I said was, “Make me a music app that looks like Spotify,” and this is what it punched back, which is kind of incredible—that it’s this good on the first shot.

A lot of folks in the Fortune 500 often aren’t saying, “Hey, I want to build a full-stack application from scratch.” They’re working on specific UI, whether it’s for Chase’s website for checking your banking details, or it’s on Netflix, like clicking the next-in-the-series button or whatever. This is an incredible environment to say, “Hey, let me hammer out some components that look gorgeous.”

You can also continue to prompt on this thing. What would be a good example? Maybe doing an audio file—you wouldn’t be able to hear it on the stream—but let’s say I can just say, “Make the play button work and the seek bar.” Let’s see what it does.

You can just keep prompting it. You tell it what you want it to do. For example, if we wanted to make an actual music-streaming application with this, we could say, “Okay, here’s the Spotify API. Add OAuth, let me log in, and play it through my Spotify account,” and it’s smart enough to actually go and do that.

You might get some errors back. We have a Fix Error button that you can click if something goes wrong, or you can debug it yourself if you’re a developer, or just Google it. The limit with the sort of things that you can build with this thing—

I can show some of the stuff folks have built. It’s really sophisticated and full-stack. You can see here that the play button is working. It does say there’s an error. It’s actually using the HTML5 Audio API to handle it, so that’s the error it threw. It says there’s nothing to play and that we need to give it an audio file. It kind of went beyond what I was expecting it to do here.

We actually have a tool that can play arbitrary audio files, and this seek bar would work if we plugged it in.

I can imagine a Suno or a Udio—I don’t know if those guys have APIs yet—but you’re an API call away from generating your own music and living a real hallucinated dream here.

I’ve seen people make stuff with this. I think Suno might have an API, because there’s a guy who made a meditation app using Bolt, and it goes to Suno and grabs some music. It says, “Make me some music that’s Zen,” and it has you breathe in and breathe out with it. It’s just crazy.

When he tweeted, I looked at the market cap of Calm, and it was, I think, $ billion or something. I was like, “I have that app pinned on my phone now.” I’m like, “Why? This is insane.” He built that in 10 minutes. It’s wild.

That disruption might be coming sooner than some expect.

Totally. Here are some examples of stuff that folks have made. This was made by a woman who’s a PM at a software banking company in Thailand. It’s her side project.

Basically, the idea with Viral Hooks—a super cool idea—is that you can come here and sign up, and this product helps you. I don’t know if you’ve ever had the inclination to be a viral TikToker or whatever.

Yeah, I’ve never tried.

You’ve got to think about what it takes. You have to have a good hook to keep people watching, right? What she did with this is that it reverse-engineers the scripts of what popular creators do to make their hooks. She made an AI agent that you give the content you want to talk about, and then it creates viral hooks for your scripts.

A week before Bolt came out, she listed this project on Upwork. I think the quote she got from a Ukrainian developer was $3,000 or $4,000, and I think the time it would take was about 3 months, which is pretty reasonable given the scope of the project we’re talking about here.

The week after that, Bolt came out. She signed up for our $50-a-month plan, and she had the thing built and launched in 2 weeks while working a full-time job. The ROI there is crazy. It’s like a 99% cost reduction, and it’s a 10× faster delivery.

There’s another case of a guy named Paul U. He made this entire CRM using Bolt. It has an AI agent built into it. If you’ve ever used a CRM, these things suck. They’re so boring to use.

He has this AI agent built into it, so if you don’t want to click through to do an action, you can say, “Hey, I met with this guy. Can you log it?” and it just does it. It’s a pretty sophisticated application he made.

It was the same deal. He spent, I think, $200 or $300 on Bolt. The quote he got from an agency was $30,000. It was going to take 6 months, and he had this done—I think it was in a month for this one—which is wild.

These are both startups that have launched and are making money at this point, just 2 tangible examples. But I should mention that both these folks are not technical. They’re not coders. They made these things completely without even having to tap developers to help them finish, resulting in incredible products.

I got kicked out. I’m on the free trial, I guess, and I’m logged in here, but it is real. I should buy this. I should support Chill CRM.

But anyway, this is kind of insane—that without any technical knowledge, you can build real products like this at this point. It’s pretty amazing. What does your pricing look like? You mentioned a monthly plan, and it sounded like there was usage-based pricing as well.

Yeah, totally. This is actually one of the interesting things that I think we were kind of the first to discover, and a lot of people have followed suit because it makes sense and it works.

A lot of these AI tools, like Copilot or ChatGPT, have had this thing where, from the days of paying for Netflix, you’re like, “Oh, I should pay $20 to get all-you-can-eat access.” But if you eat too much, you have to slow down—we’re going to throttle you.

What we ended up doing with Bolt is, instead of trying to cram it into $20, we’re like, “Hey, you can just pay for as much inference as you need.” We gave people different plans. It starts at $20 and goes up to $200. If folks need even more than that, you can buy tokens—or inference tokens—as needed outside of your subscription as well.

You can pick what makes sense to you. What we see people do is that they come in, try the free tier, love it, run out of tokens, and upgrade to the $20 tier. They’re like, “Oh, this is good. This is building incredible stuff. This is totally worth $20.” They burn through that and keep upgrading because it provides so much value.

For an engineer, going from $7 to selling it for $9,000 in that one example is huge. These folks are saving 99% compared to going with a freelancer, contracting firm, or whatever. When people start doing the math as they use the product, they naturally upgrade to the higher tiers. This is totally worth the money, right?

That’s for individuals. We also have team plans for organizations that are buying it for their employees, but it’s all based on the number of tokens that you’re using per month.

I guess I have a couple of questions there. One is, if I’m doing my math right, your per-token price is lower than the Claude 3.5 Sonnet token price. That suggests you’re probably either counting on people not to use all their tokens in a significant way, or you’re using different models.

When I was trying the product, I was like, “I wonder what model they’re using.” How are you thinking about that? In Cursor, for example, I can just choose my model, right? There’s an interesting, different approach there where you’re not making it clear to the user what model you’re using, and you have a pricing layer that isn’t fully transparent. Even though users can see their usage, they don’t know exactly where it’s going.

How are you thinking about that, and can you tell us anything about what models you’re actually using under the hood?

We’re super open about it. We use Sonnet 3.5 a lot, and we’re using other models too in various places. I appreciate the callout of, “Hey, this is cheaper than Claude,” because people are often like, “Man, this is so expensive. I’m just going to use Claude directly.” We’re like, “Go for it,” because it’s going to be more expensive.

One of the benefits of being, I think, a top 3, 4, or 5 customer of our upstream AI vendors is that we can negotiate volume discounts on this stuff. That’s one of the benefits of having a subscription-based model. Because we can project forward how much inference the user is effectively reserving, we can go and negotiate accordingly.

We can say, “Hey, we know that we certainly need this much inference over the next few months,” or whatever. That’s a huge advantage for us from a pricing perspective because we can price the thing aggressively.

One of the other cool things about this is that when people say, “This is a lot of money,” some people are like, “This is so cheap.” When you understand the ROI, it’s like, “This is so cheap.” For folks who are just learning how to build products, you’re like, “Wow, this is a lot of money.”

It’s like, well, first, you probably need to learn how to ramp up on how to best control these AI things. But second, you can actually run Bolt locally. This is a pretty unique aspect of our product versus pretty much everything else out there in this space.

When we launched Bolt, we actually launched an open-source version of it. If you go to—I think it’s Bolt.DIY...

Bolt.DIY kicks you to our official repo for this, so you can actually run Bolt using any LLM. You can choose the Gemini APIs or use OpenAI; this past week, DeepSeek landed in it. What’s great is that this is kind of our testing bed for figuring out which models perform best in the Bolt production application. When something shows great promise and produces great results in our open-source project, we pull that forward and build it into the product. You can plug in your own API keys and use this locally, et cetera.

I think it’s gotten pretty wildly popular because there aren’t a lot of good AI-agent products, and certainly not many at the level of quality we’re talking about here. Most of this stuff is kept closed source because people ask, “What’s your moat?” For us, we’ve been building the core technology for these development environments for 7 years, so it’s going to take time for someone to build something with the fidelity, speed, and accuracy we’ve got.

From our point of view, there’s only upside to putting an open-source version out there that people can build on, fork, and improve. It’s actually become pretty popular with the AI labs, because they’ll go to Bolt.DIY to test out their new models and see how well they perform in a real-world application. A lot of the benchmarks for software engineering—the evals, or whatever you have—are good to test against, but you’re not talking about a very dynamic test. It’s a specific test case that a model either passes or fails.

With the open-source version of Bolt, they can do things that are a bit more qualitative. How good is the design that comes out of this zero-shot? How good is it at providing an agentic experience for building a real application, versus just building a to-do app that isn’t even styled?

This is one of the big reasons—maybe counterintuitively—that I think Bolt has pulled away from a lot of the other products in the space. You see this with a lot of popular open-source projects: people end up consolidating around the things that are open source and that they can fork, use, and modify for their own needs. That ends up being a tide that lifts all boats, especially for whatever products the company building the open-source project is making.

We see a lot of people try Bolt.DIY and then buy a Bolt subscription, while still using Bolt.DIY. It’s a very symbiotic and cool thing that we’re doing here, because I don’t see anyone else doing this.

I noticed the last commit was 9 minutes ago at the time that you loaded the page, which couldn’t have ended better. What exactly am I downloading when I download Bolt.DIY? I understand that when I go to the main web experience, all the code is loaded into my browser and I’m running this local container in the browser itself. Am I still ultimately using Bolt.DIY in my browser, or is it a different paradigm?

No, great question. Bolt.DIY basically runs the open-source variant of Bolt.new on your local machine. When Bolt.DIY is doing the code streaming and execution, it’s still using WebContainers inside your browser to do that. All Bolt.DIY is doing is letting you run it locally on your own device, your own server, or whatever you have.

This is great if you want to have an offline experience. If you want to run DeepSeek locally, you can use Bolt offline with Bolt.DIY and DeepSeek locally, connected directly, et cetera. We see a lot of enterprises starting to pick up Bolt.DIY to run behind their VPNs and use whatever inference they have behind there.

It’s effectively just a way to host the web application at Bolt.new, and it’s designed to easily point at any inference provider.

Gotcha. Okay, yeah, that’s cool. I don’t recall seeing anything quite like that. I guess Cursor, in a way, has something similar where you can subscribe, or you can use their fork with your own tokens or whatever. But it’s always a local app, so this is definitely different, too, and it’s closed source.

It’s cool that they let you do that, but I think having it be open source is interesting. A lot of people are interested in this stuff, but how do you actually contribute to something that has real adoption, where you can see the impact?

Are all your prompt templates and everything in there, too? All the definitions of the happy paths? Can people study how you’re prompting it to make sure it’s doing the Stripe integration correctly and all that?

We’ve got—let’s see, I can find it. We have our entire system prompt and everything in this thing. There are some things that we haven’t backported from the Bolt.new side, and some stuff we just might not backport, but we have been backporting a good amount of what we’re doing.

It’s been a while since I looked at this codebase. My job as CEO, sadly, keeps me out of our codebase for the most part, but somewhere in here we’ve got the entire system prompt. There we go: “Get system prompt.” Let’s pull this thing up. Prompts—there we go. There’s the whole shebang.

This is the main system prompt for us, how Bolt actually works under the hood, which is pretty cool. There are other prompts that are chained together and that sort of thing, but this is crazy useful. This represented some months of work for us, with really smart people building it. Where else are you going to find that? Unless you prompt-leak one of the other providers, this is forkable, runnable in the product, and available for people to study.

I imagine people have made pull requests to this prompt. I’m seeing here that you have partial support for Python. I didn’t realize there was any support for Python. On the Node side, I can download random dependencies. On the Python side, I have a sort of limited Python where I can’t download third-party packages. I didn’t realize there was any support at all.

Yeah, we have some basic support for Python. The Node.js ecosystem is something we’ve worked in for about half a decade, making pretty much all the major toolchains run in WebAssembly and that sort of thing.

Python isn’t at the beginning of the trailhead, but it’s a couple of steps down the trailhead of making everything work in WebAssembly. If I go back here, I can probably use the terminal. Let’s see if we have this. If I type “Python,” we should get back the REPL or whatever.

We’ve got a version of Python running in WebAssembly here that we can use to execute Python code. I think we have some basic standard libraries baked into this thing. I know it’s on our docket to get pip added in.

For a lot of the use cases we’re seeing, when we were an IDE, it mattered a lot more to support every language. That was our 10-year roadmap or whatever. We’ve always focused on web applications, though. The key insight was that browsers don’t have a way to build web apps. The web should be able to build the web.

If you look at every other platform, the Mac has Xcode and Windows has Visual Studio. There’s no tool like that built into browsers. That was the impetus, so we’ve always been focused on Node.js and the JavaScript-based ecosystem.

We’ve added Python, and I think there are a couple of other ones, too. The entire WordPress and PHP ecosystem now runs in WebAssembly, so you can actually run WordPress in this thing. I think Laravel also runs in it, and the PHP ecosystem is probably the second ecosystem behind Node.js in terms of compatibility with WebAssembly and WebContainers at this point.

I imagine that by the end of the decade, most of the major languages and ecosystems will be running in WebAssembly.

We’ll just ask the superintelligence to handle that for us.

Totally. Right now, a lot of the issue is just how you get the engineering hours to really drill in and make that happen.

Agents.

As the market develops, it’s another difference between developers and everybody else. Developers care what they use. My dad doesn’t even want to know; he just wants to see something work. In the ideal state for him, he’s never even going to consider the code or what language it’s written in. The best product experience for him would be one where he literally couldn’t tell you at the end what language things were coded in.

That’s what’s interesting about the intersection of where we’re at. Replit is somewhat in this space, but I think they lean a bit more heavily toward developers than we do. We’re at this perfect intersection of providing a great service to developers and providing a great service to non-developers.

Especially because we made the core of this thing open source, people are contributing to it, and people want to see more things working in it. Developers want Python to work in this. We get this all the time: “I want Python apps. I want this. I want that.” People are making pull requests and making these things work.

On the other side of that, upstream, what you see working in Bolt today is the result of the past 5 years. The toolchain that’s running here is called Vite. The Vite ecosystem said that running inside WebAssembly and WebContainers is important to us because we want these browser environments, so let’s make it a reality. They committed to it, and that’s what’s making this possible.

The developers care, and it’s this two-sided ecosystem. Without developers caring, you can’t enable all these people who have never programmed before to leverage these tools. We’re right in the middle of both. Developers care about and love our product, and so do non-developers. We’re able to make this magic happen, whereas you don’t really see that happening in other products, tools, or ecosystems.

That’s cool. I’m learning a lot from that. I had no idea how far the in-browser, containerized world had come, or how many things you could do in it. I didn’t even realize it from trying the app, which I definitely spent some time trying to make something myself, although I didn’t get that deep into it.

That’s the point: anyone should be able to use this and be completely unaware of what’s happening under the hood. That means we did our job right.

What are some of the other foundational technology pieces that you’re tapping into? For example, you mentioned Stripe, and you can see Supabase in the UI there. I saw mention of Vercel’s AI SDK. Some of those are fairly obvious choices at this point. Stripe has certainly emerged as a standard, but could you run down the list of the opinionated decisions you’ve made and why?

There’s one track that we’re opinionated on, and this is really more for people who aren’t developers. We want to provide a smooth path where they’re not going to run into a lot of errors. It should be great even for developers who are just looking to quickly build a product or something.

On that path, it’s Vite and React, which we’ve supported for the past 5 or 6 years. That’s the development tooling and the framework. For auth, databases, webhooks, and that sort of thing, Supabase provides those capabilities. You can click the “Connect Supabase” button, create a project, and spin up an actual database for the application.

You can have a database with auth, a way to create rows, and Postgres backing it. You can also plug in Stripe and accept billing, as you saw on the Chill CRM site. That’s powered by Stripe for subscriptions and that sort of thing.

The final thing that’s cool about Bolt—let me refresh the page to get back to a fresh slate. This is the beautiful, wonderful thing: if something goes wrong, you can usually get back to a fresh slate. Maybe not; I might have broken my development account before we came on here.

The cool thing about Bolt is that, because we’re running an operating system in the browser here—you mentioned this before, and I didn’t actually answer your question—you can make something cool, but how do you actually get it onto a URL and do something useful with it? How do you actually have a domain?

We have a built-in integration with Netlify, so you don’t even have to sign in to Netlify to do this. It’s built into every Bolt project. You can just click this “Deploy” button.

I’ll flip back to the code view because this is cool. This is running a production build using my CPU. Normally, you’d spin up some cloud CI box or whatever to build a production website and deploy it live on Netlify. That’s the URL, and I can share this with you.

If I want to add my own domain, connect this to a Git repository, or whatever, I can click on this link, which will take me to Netlify and attach it to my account. My spotifyclone.com points directly at this thing. Anytime I deploy here, it will update that site.

If I want to make the backgrounds neon or something, as I make changes to this thing, it’ll update them. Once it’s done making those changes and we make sure it’s good, I can hit the Deploy button again. It’ll run another build and put it right back onto that URL.

If we had a production.com domain pointed at this thing, it would update live with that. It completely removes the deployment part of the question from this experience, which is usually one of the more challenging parts.

Deployment is such a nightmare. I’m very excited about things that make deployment easy. Replit, which you mentioned, was one of the first things I saw that changed my paradigm there.

This is doing something similarly cool. The Replit team did a great job baking deployment into the product, which I think is great for certain types of apps. What’s nice about us having a partnership with an actual deployment platform is that deployment is what they do as a business. It’s reliable, you can attach domains to it, and you can build real products and teams around it.

That’s not to say that having an in-house deployment solution, like what Replit is doing, isn’t useful. I think they’ve done a really good job there. But a lot of people want to host something with a real domain and that sort of thing.

I’ll kick off another deployment here. This is what it currently looks like for reference. I’ll let it go ahead and do a production build again.

Go ahead and do that.

If I refresh—boom, you see our neon colors. It’s insanely simple to get this thing live again. That’s probably one of the most magical parts of the Bolt experience: having a one-click way to get this thing live on a real production URL.

That’s cool. What’s coming next? Candidate ideas I’d be interested in hearing your take on: obviously, o3-mini should be coming soon, allegedly bringing another significant jump in coding ability. Agents in general are a big buzzword.

When I’ve been doing this kind of AI-accelerated app development, I’ve noticed that a lot of my time is spent copying and pasting things around, and even more time is spent testing the flow that I just had the thing code. I’m starting to wish for Claude computer use to code it, or now we have Operator, which obviously has limited access at the moment. I do pay $200 a month, so I’ve had a chance to use it.

I wonder if you’re expecting to create an AI user or an AI tester. That seems like it would be the next biggest chunk of time for me to eliminate. If I could zoom out one level and go from, “What’s the feature I want to build?” I’ll often take that to o1 Pro because I pay for everything. I’ll have it do an analysis, make a plan, and ensure that my overall roadmap for the feature is good.

I’ll usually put my full codebase in there if it fits. Then I have a step-by-step plan, which I can take to the coding agent. Most of my experience recently has been with Cursor, and that usually works pretty well. But then I have to ask, “Did it work really well?” I have to go find the edge cases.

I wish I could zoom out one level further and say, “Here’s what I want you to do. Go do it, test it, bang on it 5 times, and fix the errors that come up.” I feel like I’m already 5 times faster than I used to be, maybe 10 times faster in some cases. If I could do that, I feel like I’d consistently be more than 10 times faster, and maybe genuinely getting into the 20-times-plus range for some scenarios.

That’s what Devin is trying to do, right? I was talking with one of my buddies, Sean Wang—you might know him, or you might at least have seen him on Twitter. He’s a really smart guy. He’s been doing a lot of work in this space.

swyx.

Yeah, swyx. I should refer to him by the thing that people know him by. I call him Sean because I met him in person before I knew him online. Everyone calls him swyx, but he’s an awesome guy, an angel investor in the company, and a good friend of mine.

We sat down a couple of weeks ago and were talking about the breakdown of the different products in the AI software-engineering space and how they’re oriented. My takeaway—and I think Sean would probably agree—was that the problem with something like Devin, which isn’t a knock on their product because I’m sure it’s great for certain cases, is that when you tell an agent to go do something that’s going to take a while, it’s going to do a lot of things during that time. It’s going to spend a lot of inference, and a lot of things can go wrong.

Depending on what stage of the process things went wrong, they can cascade. “Wrong” doesn’t necessarily mean an error happened. It might mean the agent got confused, misinterpreted the directions, or something like that.

That’s the challenge with agents. When you start baking in a process where the agent is going to do a whole bunch of things, the odds of it collapsing increase the more steps you add. These systems just aren’t at the level of fidelity you’d need to send them off into the woods to do a meaningfully sized set of tasks. That doesn’t mean they can’t work in some capacity, but they don’t yet have the fidelity you’d need.

Coming back to your earlier question about Bolt, what’s the success rate? From what I understand, the success rate for these longer-running, agentic systems like Devin is pretty low. People aren’t consistently saying, “Thumbs up, I’m super happy with the result.”

When you flip to something like Bolt, there are a lot more people getting immediate results, to the point where the ARR just continues to ramp. If Bolt makes a mistake, it didn’t go off for 20 minutes burning inference just to make a chain of decisions that were fundamentally not what you wanted.

I think having a human in the loop—where the human is guiding the thing and verifying that it’s not screwing things up—is where you can really squeeze an incredible amount of value out of these systems right now. I’m a little hesitant to move away from that. We’re doing R&D on the longer-running stuff, but I’m hesitant to pull away from the human-in-the-loop model because humans are going to be an important part of the creation process for the foreseeable future.

As far as adding some level of automated testing, there’s certainly stuff that can be done. You could have the system write unit tests up front, so as it’s building, it ensures that it’s aligning with those tests. But part of the trick is figuring out how to write unit tests if the user isn’t technical, and how to ensure those unit tests are actually good and representative of what the end user wanted.

That’s the big question around this stuff. That’s my current worldview on how to improve these systems generally and what limitations we pragmatically and immediately see. We’re investing across the board in those areas.

I think that’s really interesting. In preparing for this, I lined up 4 different products and basically tried to build the same app with all of them: Bolt, Replit, Devin, and Lovable. I had the most experience with Bolt and would say Devin definitely stood out as the most different experience from the others in terms of the paradigm.

It is different for the reason we’re discussing: it just keeps going. I feel like I do want that, but I don’t want to watch it. At least when I tried it, which was 10 days ago or whatever—these things are changing fast—that was the experience.

With the other 3 products, when I came back, I was literally just rotating through them: “What’s the status of this one? What’s my next instruction?” I was the outer-loop agent, and each one was doing its inner loop.

What I found weird about the Devin experience was that I didn’t know where I was when I came back. If I had watched it, I would have known where I was, but I didn’t want to watch it. I wanted to do other things. That’s one of the big promises of this.

It feels like there’s a way to solve that. If you imagine a good intern or junior person helping you with a project, the piece that I feel is missing is that I do want them to take initiative. I do want them to test it before they bring it to me. That’s definitely an expectation for a human developer I’m working with: don’t bring it back to me without having tried the happy path.

I can expect there to be edge cases that you haven’t sanded down, but if you haven’t been down the fairway and confirmed that it works, you’re not doing your job. At the same time, I want a summary of that. I want to know—not in a way where I have to go back and read through your experiment logs—where I’m at, what you did, how you tested it, what you confirmed is working, and what questions you have.

That interaction layer hasn’t been nailed yet, but I do think I want several extra turns. I haven’t seen anything that gives me that human experience of, “Here’s the update, boss, on everything that happened since the last time you were here.”

It would almost need to trigger when you refocus the browser tab, or based on some other signal that the user is back and it’s time for an update. I was coming in and it was just midstream. It was working, and I was thinking, “I don’t know where you are or where you’ve been.”

I do think that will improve with time. I’m definitely willing to wait longer and pay for more inference tokens if I can get bigger chunks of things done.

It’s definitely going to happen. That’s kind of what we kicked off with the pricing model, where you can buy more. Claude 3.5 Sonnet basically got AI coding to the point where the more money you put into it, the more realistic your expectation of the value it can give you in return becomes.

Before that, with the previous frontier models, that wasn’t the case. We tried building Bolt a year ago, in February 2024, with the frontier models at the time, and they just couldn’t do it. The code was too unreliable, and the design output was ugly, if it even worked.

As these systems improve, I absolutely want that, too, because I do this all the time with my own team. I’ll say, “Hey, can you go ship this?” They’re brilliant people, they’ve worked with me for a while, and they have a sense of what I’m looking for. If an AI system could deliver on that, it would be worth every penny and much more.

The trick is really the accuracy and the user experience. I don’t think we’re far away. I feel like we’re probably a model or 2 releases away from the fidelity being good enough that you can meaningfully start doing that for at least some types of workloads. You’ll be able to have longer-running agentic processes that you can trust to do what you want them to do.

It’s a tricky balance for you and everyone else taking different approaches to this. To varying degrees, you want to deliver value to customers and grow today, build momentum, and get the positive feedback that makes everything better, including hiring and everything else.

You need to be in the sweet spot, but you also need to be getting ahead because we know the sweet spot is moving. That’s definitely been a challenge that I’ve experienced firsthand. How do you do both?

That might actually be a great closing question. That’s about all the questions I had, but I’d be interested to hear how you think about balancing today versus tomorrow.

It’s a good question. We’re pretty laser-focused on making our AI agent incredible today. We’ve got irons in the fire on a handful of R&D projects, but there’s a very clear line of sight for our product to enable people to build incredible software. That’s already happening today, and it keeps getting better even with the current state of the models.

That’s primarily where our focus is. There’s also a part of this where tsunami waves keep hitting every 6 to 12 months with these models. There were some products in this space—Replit, v0, and Lovable—that were around before Bolt existed, 6 or 9 months ago or whatever. When Claude 3.5 Sonnet came out, they had to completely reinvent their product experiences because all the work they had done on their agents for previous models no longer mattered.

In some cases, they straight-up pivoted their product offerings. I look at that and think about the future: How do you ride tsunami waves into the shore, then paddle back out and catch the next one instead of getting wiped out by it?

It’s a delicate balance, just like with professional surfers. It isn’t easy. It takes a realistic perspective on the probabilities of how things are going to land and what the next wave could be, and then aligning yourself to catch it. Sometimes you just can’t, of course.

That’s how we view it internally and how we hedge our bets as we look toward the future. We’ve seen the results of 1 or 2 of these waves at this point and how they’ve transformed the way products are oriented, so we’re pretty open-minded about what will happen.

We just announced that we raised a Series B a week ago: $105.5 million. We’re looking to aggressively expand our team. We’ve scaled to tens of millions of dollars in revenue and more than 2 million registered users with a team of 20, so we’re severely understaffed for the demand we’re seeing. The last time I checked, we had around 50,000 or 60,000 active customers.

Cool, well this has been excellent. I really appreciate the time and the product demo and some of the deep tech stuff that I didn't know previously, and you guys are on an unbelievable trajectory. So definitely check out—what was the careers page again?

If you go to bolt.new, there's a link at the top that says, like, "We're hiring," so you can click that, or you can just go to stackblitz.com/careers. That's like the direct link to the thing.

Alrighty, cool. Again, this has been amazing: Eric Simons, founder and CEO at StackBlitz, makers of Bolt.new. $20 million ARR in just the first 8 weeks, $100 million raised, and an exciting future in front of you guys.

Yeah, thanks for having me.

Thank you for being part of the Cognitive Revolution. It is both energizing and enlightening to hear why people listen and learn what they value about the show, so please don't hesitate to reach out via email at TCR turpentine dot co, or you can DM me on the social media platform of your choice.