WebContainers, and the boundary it draws
A WebContainer is a Node.js runtime compiled to WebAssembly and executed by your browser. The file system, the package manager and the dev server are all in the tab.
The consequences run through everything else in this page.
Instant feedback. There is no round trip to a build server, so changes appear immediately and the agent sees real errors from a real dev server rather than predicting them.
It runs on your hardware. Memory and CPU are yours. A large project in a browser tab is demanding, and older machines struggle in a way they would not with a server-based tool.
JavaScript and TypeScript only. This is a hard architectural boundary, not a roadmap item. Python, Go, Ruby, Java, PHP and anything else needing a different runtime cannot run here at all. Replit runs on servers and has no such limit — if your stack is not JavaScript, that comparison ends the decision.
What the agent actually does
You describe an application and Bolt scaffolds it: picks a framework, writes the files, installs dependencies, starts the dev server and shows the result.
From there you iterate conversationally, and you can also edit any file directly in the built-in editor. That dual mode matters — conversational iteration is fast until it is not, and being able to drop into the code and fix one line yourself avoids the loop where you describe a small change three times.
Because the runtime is present, the agent reads genuine failures: a failed install, a type error, a runtime exception. It corrects against reality rather than expectation, which is a meaningful advantage over generators that produce code and stop.
Token economics, and where projects go wrong
Pricing is token-based, and the pattern that exhausts an allowance is specific enough to name.
Generation is cheap relative to debugging. When the generated code has a problem, each attempt to fix it re-reads the project context, and a stubborn bug can consume more tokens than the original build. That is exactly when you cannot stop, because you have a half-working application.
Practical mitigations: keep the initial prompt specific rather than sprawling; fix small things by editing the file yourself instead of asking; and start a fresh project rather than pushing a badly-shaped one through twenty correction rounds.
What comes out, and whether it is safe to ship
The output is a conventional project — real files, real dependencies, deployable and pushable to GitHub. There is no proprietary format and no runtime lock-in.
The architecture is conventional at best. For a prototype that is entirely fine. Before anything carries real users or real data, someone needs to review authentication, input validation, dependency choices and how secrets are handled — the generated code is plausible rather than audited, and the users most attracted to this tool are the least equipped to check.
That is not a criticism unique to Bolt; it applies to every tool in this group. It is worth stating because “it runs” and “it is safe” are different claims and the tool only demonstrates the first.
All you need is a browser tab
- A modern browser. Genuinely nothing else. Chromium-based browsers give the most reliable WebContainers behaviour.
- An account, with a free allowance of tokens; paid plans for sustained use.
- A reasonably capable machine — the project runs in your browser, not on a server.
- Enough judgement to review generated code before anyone relies on it.
Who it is for
Founders and product people validating an idea, where a clickable prototype this week beats a well-architected one next month.
Developers scaffolding a new front-end project — the boilerplate of a fresh app is exactly the work worth delegating, and the output is a normal project you can then take seriously.
Designers and non-developers who can describe what they want and need something real to show without asking an engineer.
It is a poor fit for teams with an existing repository, for anything outside JavaScript, for production systems where architecture matters, and for machines without headroom.
What the browser runtime buys you
- Zero setup and an immediate preview, because the runtime is in the page.
- The agent sees real errors from a real dev server.
- Full file access — you are never stuck in a chat loop.
- Deploy and push to GitHub from the same place.
- Nothing installed on your machine, so it works on locked-down or borrowed hardware.
- Conventional output with no proprietary format.
The constraints you cannot design around
- JavaScript and TypeScript only — architectural, not a gap to be filled.
- Token pricing that debugging consumes fastest, at the worst moment.
- Runs on your hardware, so large projects strain the browser.
- Generated architecture is conventional and needs review before production.
- Weak on existing codebases — it is oriented around starting, not continuing.
- Browser dependence: no offline work, and a crashed tab is a real interruption.
Getting your project out
Push to GitHub and you have an ordinary repository that runs anywhere Node runs. This is genuinely low lock-in and it is worth using early rather than at the end — pushing on day one means the tool is a starting point rather than a dependency.
What does not transfer is the conversation history that produced the code, so the reasoning behind decisions lives only in your head. Commit messages and a short README written while it is fresh are cheap insurance.
If JavaScript is not your stack
- Lovable — the closest competitor, more attention to visual design, real backend included.
- Replit — server-based, so not limited to JavaScript, and stronger for learning.
- v0 by Vercel — interfaces only, for a React project you already have.
- Cursor IDE — the right tool once the prototype becomes a codebase.
Compiled from StackBlitz’s Bolt.new documentation and public sources. We have not hands-on tested this tool. Last reviewed 16 August 2026.
Alternatives
- Lovable — the closest competitor, with more attention to visual design.
- Replit — server-based, so not limited to JavaScript, and stronger for learning.
- v0 by Vercel — interfaces only, for an existing React project.
- Cursor IDE — the right tool once the prototype becomes a codebase.
Compiled from StackBlitz’s Bolt.new documentation and public sources. We have not hands-on tested this tool. Last reviewed 16 August 2026.
