Lenny's PodcastEric Simons: How WebContainer fueled Bolt's 40M ARR breakout
Through WebContainer running dev environments in the browser via WebAssembly; StackBlitz scaled Bolt to 40 million ARR with a 20-person team.
CHAPTERS
- 0:00 – 5:36
Bolt and StackBlitz in one minute: what it is and why it matters
Lenny introduces Eric Simons and frames Bolt as a historically fast-growing AI code product. Eric explains Bolt’s core promise: prompt-to-full-stack (and mobile) apps with results in minutes, including databases and hosting.
- •Bolt = text box → web or mobile app generation
- •Full-stack output (not just static sites): DB + hosting + real software
- •Speed as the core user value: meaningful results in ~1 minute
- •StackBlitz’s background building browser-based dev environments
- •Context: growth is extreme but built on years of prior work
- 5:36 – 10:40
‘From near-death to $40M ARR’: the growth story and why AI startups can scale so fast
Eric shares the company’s precarious position before launch and the shock of going from near shutdown to tens of millions in ARR within months. They discuss why the demand is real and how AI products may redefine what ‘normal’ startup growth looks like.
- •StackBlitz was nearly out of money when Bolt launched
- •0 → $20M ARR in ~2 months; crossed $30M and nearing $40M soon after
- •~3M registered users; ~1M monthly actives
- •Eric’s skepticism: expecting the growth to suddenly stop, but it didn’t
- •Macro view: AI products can deliver immediate, provable ROI
- 10:40 – 13:27
Live demo: building a Spotify clone in Bolt (and why Bolt feels faster than competitors)
Eric demonstrates Bolt by prompting a Spotify clone and highlights the differentiator behind the scenes: a full dev environment runs inside the browser. He contrasts Bolt’s local-browser compute model with cloud VM-based tools that can be slower and less reliable.
- •Demo prompt: ‘make a Spotify clone’ → working app quickly
- •Bolt’s key advantage: speed + reliability, not just UI features
- •WebContainer runs an OS-like environment in the browser using local CPU
- •Cloud-VM IDEs can take minutes to boot and can get stuck
- •Bidirectional AI-agent + in-browser environment enables tight iteration
- 13:27 – 15:32
Deploying from the browser: Netlify + Supabase integrations and the ‘Wix is harder’ insight
Eric shows one-click deployment to a real URL and explains why Bolt’s compute model enables a permissive free tier. He argues many people turn to Bolt even for “simple websites” because traditional site builders feel complex—and Bolt can go far beyond static sites.
- •Built-in deploy flow to Netlify; database integration with Supabase
- •Production build runs in-browser, reducing platform cost to StackBlitz
- •Easy sharing: live URL and optional custom domain workflow
- •Observation: people use Bolt instead of Wix/Squarespace due to complexity
- •Bolt can iterate into functional apps (not just landing pages)
- 15:32 – 19:14
Native mobile in Bolt: Expo partnership and real-time phone previews
Bolt expands beyond web apps by generating React Native apps through Expo tooling. Eric demonstrates scanning a QR code to preview a native app on a phone and describes how this changes product collaboration and prototyping speed.
- •Expo partnership enables prompting native apps into existence
- •QR code preview: test the native app live on your phone
- •Hot reload-style iteration as prompts change the code
- •Enables non-developers (PMs/designers/entrepreneurs) to ship real apps
- •Potentially faster than producing extensive Figma flows for validation
- 19:14 – 25:04
Seven years to WebContainer: the deep-tech bet behind Bolt
Eric explains WebContainer as the foundational technical breakthrough: a WebAssembly-based environment that boots quickly and runs real toolchains in the browser. He traces the inspiration to Figma’s early deep-tech approach and details why local compute scales better than cloud VMs.
- •WebContainer was the company-defining bet; took ~4–5 years to build
- •Inspired by Figma’s WebGL/WebAssembly-era deep tech journey
- •Browser APIs (Wasm, shared memory, service workers) made it feasible
- •Local compute model scales (billions of devices) vs limited cloud VMs
- •Better free tiers and fewer abuse vectors when compute runs on user devices
- 25:04 – 29:36
Surviving long enough: contrarian choices, low burn, and ‘tech-first then problem’
They unpack counterintuitive lessons: building tech before a clear monetizable use case, ignoring hiring exuberance, and focusing on staying alive. Eric shares how conservative spending and conviction let them reach the moment when AI made Bolt viable.
- •Tech-first approach can work when a platform shift is underway
- •‘Just don’t die’: maximize shots on goal, keep burn extremely low
- •Bootstrapped early; raised later but spent conservatively
- •Resisted 2020–2021 headcount exuberance; would’ve killed the company
- •Entrepreneurship requires non-consensus judgment calls
- 29:36 – 34:15
The tweet launch and the chaos after: pricing, infra, and GPU limits
Eric recounts the launch via a single tweet and the immediate ARR jump that kept increasing day after day. The team scrambled to fix missing basics, rebuild pricing, and manage scale issues—including upstream GPU constraints from model providers.
- •Launch day: strong reception; ARR jumps felt ‘too good to be true’
- •Bolt built in ~90 days; many basics missing (even mobile responsiveness)
- •Pricing had to be rebuilt quickly (users blew through $9 plans fast)
- •Inference demand triggered supply constraints; provider GPU shortages
- •Small team did everything—execs handling support, constant firefighting
- 34:15 – 40:46
How a 15–20 person team keeps up: ‘more context per head’ and high-trust execution
Eric attributes their ability to move fast to both their tech and unusually strong team continuity. He describes a culture of agency, low ego, and end-to-end ownership—enabled by keeping headcount low and context high.
- •Core team stayed together for 5+ years—rare in startups
- •Hiring for intrinsic motivation, low ego, and title-indifference
- •Remote-first; many hires came from the StackBlitz community
- •High agency: engineers fix issues end-to-end without committees
- •High trust + shared context enables rapid decisions under pressure
- 40:46 – 44:02
Prioritization under hypergrowth: balancing customer feedback with ‘nobody asked for it’ bets
They discuss how Bolt decides what to build amidst a flood of requests. Eric emphasizes intuition and experience, and cites native mobile support as a major win that wasn’t strongly requested but proved transformative once shipped.
- •Not all high-impact features are directly requested by users
- •Example: native mobile support became one of the biggest launches
- •Balance ‘triage the pain’ with investing in new capabilities
- •Prioritization likened to a chef: feedback + creative bets
- •Developing ‘gut instinct’ comes from years of market lessons
- 44:02 – 48:43
Operating cadence and tooling: daily all-hands, Linear/Notion/Figma, and lightweight PRDs
Eric shares a surprisingly intense communication approach: near-daily whole-company syncs during peak growth to minimize “fidelity loss.” They also describe their tooling stack and why they still use PRDs—kept minimal and often paired with real prototypes made in Bolt.
- •During hypergrowth: whole-company Zoom daily (8am PT) for ~1 hour
- •Goal: near-zero communication loss; everything reviewed together
- •Tooling: Linear (engineering), Notion (roadmap/PRDs), Figma (design)
- •PRDs stay light to avoid being ignored; focus on outcomes and alignment
- •Prototypes in Bolt can replace many static Figma flows for fidelity
- 48:43 – 52:24
Real-world adoption: from prototypes to paid products, and integrating with existing code
Eric gives examples of users building revenue-generating software quickly and cheaply, and discusses where Bolt fits in companies. Bolt can open repos, but large codebases remain challenging; many teams use it for greenfield builds, marketing sites, and rapid product development acceleration.
- •Example: non-coder built a CRM in ~3 weeks with Stripe + AI; spent ~$300
- •Massive cost/time compression vs agencies (e.g., $30k/6 months → weeks)
- •Companies use Bolt for marketing sites/landing pages instead of Webflow
- •Repo support exists, but large codebases are still hard for models today
- •For big legacy systems, Bolt is better for new surfaces and prototyping
- 52:24 – 59:57
Limitations today, and why PMs become more valuable in the AI era
They outline Bolt’s biggest limitation—handling very large existing codebases—and why tools like Cursor remain better for deep developer workflows. Eric argues PM-style skills (scoping, specifying, debugging with the agent) map directly to succeeding with AI builders and will reshape org charts.
- •Main limitation: large/complex existing repos reduce reliability today
- •Cursor-style tools remain essential for developer-heavy workflows
- •Success with Bolt requires scoping, clarity, and iterative debugging
- •PMs/designers gain leverage: they can ‘write the ticket’ and ship changes
- •Org charts may shift: fewer UI engineers per pod, more PM/design ownership
- 59:57 – 1:13:57
Skills for the future and why coding got ‘agent-ready’: Sonnet, determinism, and reinforcement learning
Eric explains why coding is a uniquely strong domain for LLMs: software is deterministic and can be reinforced at scale, unlike many professional domains. They discuss how Claude Sonnet crossed a threshold that made reliable app generation possible and why the trajectory suggests rapid improvement ahead.
- •Advice: learn to leverage AI tools + understand system fundamentals
- •Bolt didn’t work a year earlier—code quality wasn’t reliable enough
- •Sonnet was the turning point that flipped AI from assistive to primary builder
- •Coding is deterministic: run/pass feedback enables massive RL improvement
- •All major labs are now ‘gunning for coding’ due to trillion-dollar upside
- 1:13:57 – 1:20:16
What’s next for Bolt: Figma-to-app import, Slack agent, and building Bolt with Bolt
Eric previews upcoming features aimed at fitting into existing workflows: importing Figma designs directly into Bolt and a Slack bot that acts like a developer in team threads. He also shares how the team uses Cursor and Bolt internally for development and prototyping.
- •Figma import: add bolt.new before a Figma URL to convert design → app
- •Partnering with Anima for high-fidelity Figma-to-code translation
- •Slack integration: @Bolt in a thread to implement discussed changes
- •Internal stack: Cursor for coding, Bolt for prototyping, plus Claude/ChatGPT
- •Vision: integrate Bolt into how teams already collaborate and build
- 1:20:16 – 1:28:50
Getting the most out of Bolt + Eric’s origin story: the AOL office years
Eric offers practical prompting advice: treat Bolt like a developer coworker or a Jira/Linear ticket, mixing specificity with room for creativity. The episode closes with Eric’s personal story of scrappy early startup life (including living in an AOL office) and where to find Bolt and reach him.
- •Prompting tip: write requests like a clear ticket to a teammate
- •Beginner exercise: generate and deploy a personal website from LinkedIn bio
- •Bolt Builders program: human experts to help users get unstuck
- •Eric’s scrappiness story: lived in AOL office, ‘$1/day’ burn rate era
- •Where to find: bolt.new, social handles, and direct email for feedback
