High Signal Podcasts Evidence ledger
Method
Browse
← Back to evidence

Evidence receipt / evaluation

Published · transcript-backed

Eric Simons: evaluation

13 Mar 2025 Lenny's Podcast Inside Bolt: From near-death to ~$40m ARR in 5 months—one of the fastest-growing products in history | Eric Simons (founder and CEO of StackBlitz)

“Because that's kind of what we've seen with Bolt where, if you want to build a product that's going to be able to scale to that size, you have to look at all factors and go, "We have to build, make sure the technology provides the best experience, zero latency, transient cost.”

— Eric Simons

Source trail

Everything needed to verify it.

Speaker
Eric Simons
Attribution
Verified speaker
Claim type
evaluation
Recorded
13 Mar 2025
Publisher
Lenny's Podcast

Transcript context

…A hundred percent it is, yeah. And I would say this is, surprisingly to me, it's still one of the contrarian viewpoints of our company. Because over the years it was like, when we first... And that, the WebContainer was the bet, that we made the company on. Just to be clear. StackBlitz was a browser-based, deep technology play on, "Can we make a web assembly based operating system that can boot in a browser, in like a hundred milliseconds, and run full on development tool chains?" That was really it. And we'd gotten the idea for this, and the insight that this might be possible, because back when my co-founder and I came out to the Valley, he and I grew up down the street from each other in Chicago, we wrote code together at 13, and been building stuff ever since. And we came out to the Valley in 2012, and we just had the good fortune of bumping into Dylan Field and Evan Wallace when they were building Figma, in the early days. And that was, I don't think a lot of people know that Figma was also a browser-based deep technology play. Their first pitch for Figma, they didn't have a design tool. Their first pitch was this 3D ball dropping into water, inside of a browser town. And the pitch basically was, "Browsers have this new capability called WebGL," the predecessor to WebAssembly, "and with these things, for the first time, you could actually create a graphics rendering engine, that you could then build a design tool on top of. But you're going to have to write that rendering engine from scratch, because nothing exists that can just compile into WebGL, or whatever. And if you want the performance you need, et cetera, it's going to take us years to do, but if we do it, we think this will change everything for design." And obviously, we know how that story has panned out now. And back in 2017, 2016, 2017, Albert, my co-founder and I, saw the same sort of story begin to play out, but for web development and development environments. And specifically there was some stuff that landed in browsers like WebAssembly, shared memory, service workers, these different APIs. And we were like, "Oh, wow. It should be possible, theoretically, to write an operating system in WebAssembly that could run Node.js, and NPM and all the tool chains on top of it, that you need to do web development." And that would be huge, because setting up developer environments, it's a pain for beginners. A lot of people churn out. The first thing you do when you learn how to code is not even learning how to code, it's how to set up your computer to even start writing the code. If you go join Netflix, or any of these other fan companies, the first month or two is you being onboarded, to run that stuff on your computer and set up your environment. And we're like, "If we could just have that be something, you click a link and it just boots in your browser, that'd be huge." nboarded, to run that stuff on your computer and set up your environment. And we're like, "If we could just have that be something, you click a link and it just boots in your browser, that'd be huge." It's also, if you look at the other productivity apps that have really worked on the web, they've all had this compute model, right? Figma, when you open a Figma document, there's not like some cloud VM that gets spun up for you to render the documents. You're dragging things around. It's using your CPU and your memory to do the work. Same thing with Google Docs. That's the only model that's ever scaled to a billion users. And so, when you look at Cloud IDEs, like Cloud 9 was the first one, back in 2009 or so. The way these have always worked is that your browser's basically doing nothing, when you go to that. Every user that gets connected, there has to be a cloud VM that gets spun up for them, and then your browser's just taking your keystrokes, sending it to the server, and then sending back the results of it. And that's how all these other AI code, text to app sort of tools work. They're all using cloud VMs. And the problem is, on a small scale it can work, but as you scale it up, I mean there's not even a 100 million VMs to rent, on the planet. But there are a billion devices that you can run this stuff on. Because that's kind of what we've seen with Bolt where, if you want to build a product that's going to be able to scale to that size, you have to look at all factors and go, "We have to build, make sure the technology provides the best experience, zero latency, transient cost. " There's a permissive free tier, because the other problem with the server is, you end up, if you have a free tier, people are mining Bitcoin on it, they're DDoSing people using your servers. So inevitably, you have to nerf these things and roll them back. But if it's all done on the end device, it doesn't matter. So anyways, WebContainer was the key piece, and what we struggled with, it took us four or five years or something, to build WebContainer. What we struggled with for the years after that was just how to build a product around it, because developers loved it, but they weren't using it in ways that they would pay money for. And as much as the nerd side of me wished that that would be enough, that it was like, building cool technology was enough. It's like, "It's not. We're here to build a venture scale company." And so that was kind of why we were high at the end of the journey, where it was like, we're taking shots on goal. And at some point, this got a connected bat, right? There's a lot of really interesting lessons from this journey, that I think are counterintuitive. One is, you basically were building a tech first, and then looking for a problem to solve later. Which is often what people tell you not to do. And it worked out, in this case. The other interesting takeaway here is, it feels like it's a similar moment to when AJAX came out and then everyone's just like, "Wow, you can build new things here." So it feels like there's a lesson here of just, "If there's a new technology that has enabled, something big that we think may, let's just work there for a while, and see if something comes up." And then I think the other lesson here is just, as a founder, just survive as long as you can. Because you may find something that works.…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.

Search evidence