What Bolt is genuinely for
Bolt is a capable agentic full-stack builder. It runs a Node.js environment in your browser via StackBlitz's WebContainers, has a Plan Mode that outlines steps before executing, supports multiple agent backends including a Claude Code agent, and as of mid-2025 ships Bolt Cloud: first-party managed hosting (*.bolt.host) with a native database, auth, file storage, edge functions, and analytics. There is real-time multiplayer collaboration. Netlify remains an optional deploy target alongside Bolt's own hosting.
For a founder who wants to go from a natural-language description to a running full-stack app in minutes — without a local environment, without a Docker daemon, without anything installed — Bolt removes friction that is genuinely annoying to remove. It is not a naive single-shot generator; it has an agentic loop that reads build errors and retries.
For concept validation — testing whether a data model works, whether a user flow makes sense, whether a feature is worth building at all — Bolt is a reasonable tool. The speed is real.
The question is what you do after the concept is validated.
The sandbox and the deployed app
Bolt's in-browser development sandbox runs inside WebContainers. That environment is in-memory, HTTP-only, no raw TCP — useful constraints for a secure browser runtime, meaningless for evaluating what a deployed app can do.
The distinction matters: once you deploy to Bolt Hosting, the application runs on real hosting infrastructure — not subject to those in-browser sandbox constraints. HTTP APIs like Supabase work in the sandbox; Bolt's own native database and auth work in the deployed app. Do not conflate the dev sandbox with the deployed product's capabilities.
What the deployed product still does not have: a CI/CD pipeline, a staging environment that mirrors production, GitOps, observability, or backups you control. The Bolt Hosting infrastructure is managed by Bolt. You can add a custom domain and configure DNS and SSL — that is domain control. It is not infrastructure control. You are not provisioning or operating the underlying cloud.
There is currently no bring-your-own-cloud (BYOC) path inside Bolt. The only route off-platform is to export your source to GitHub and self-deploy elsewhere — which means you are now operating the infrastructure yourself.
No review, no provenance
Bolt generates and runs. The built-in version control is a linear visual version history. There is no native branch, PR, or review workflow inside Bolt. A GitHub integration exists, and once connected, branching and PR creation happen inside GitHub — not inside Bolt. Bolt is not in that review loop.
What Bolt's agentic loop does: reads build errors and retries. That is agentic error-fixing, not a test suite. There is no test generation, no CI gate, and no merge-blocking policy. The agent fixes what breaks the build; it does not verify behavior before promoting to production.
There is no record of what the code depends on, what sources were cited, whether dependencies have known vulnerabilities, or what tests were run before the code was considered shippable.
When something breaks in a Bolt-originated project, the debugging surface is the code, the symptoms, and your intuition.
We work differently. Every change is a branch. Every branch has a PR. Every PR has a provenance trail that shows what changed, what sources were cited, what verifiers ran, and what test output the change produced. A human engineer reviews and signs before it merges. The trail records, for example: cited at L18 — nextjs.org · cookies() · 14.2 docs; verified at L20–22 — owasp cookies cheatsheet · 2024-09; tested at L18–22 — session.spec.ts · 4/4 pass; pinned at the package level — next@14.2.5 · iron-session@8.0.3. Trail archived at /launches/2026-05-14/2a91. Re-run any check months later.
The trail outlives the run. If a dependency ships a CVE six months from now, you can pull the original trail and compare.
The dependency problem
Generated code depends on libraries. In our testing on Bolt-generated projects (June 2026), generated package.json files used caret ranges (^) rather than exact version pins — meaning npm install at a later date can silently pull a newer minor or patch release than was present when the code was written. This is a testable, observable behavior, not a documented policy claim; Bolt may behave differently by project or over time.
What is documented: there is no CVE check and no license clearance in Bolt's output. A dependency with a known security advisory can appear in a Bolt-generated project with no warning. A dependency licensed under AGPL can appear in a commercial project with no flag.
These are not exotic edge cases. They are routine software supply chain risks that any generation tool skips unless it has an explicit verification layer.
launch.ist pins every dependency to an explicit version. The developer agent checks every dependency against the GitHub advisory database before the change merges. The lawyer agent checks license compatibility across your full dependency graph. Both results appear in the provenance trail, signed before merge.
Infrastructure you don't control
Bolt Hosting is fully managed by Bolt. You configure a custom domain, DNS, and SSL — that is real and useful. You do not provision or control the underlying servers, cluster, or cloud account. There is no BYOC option. The infrastructure decisions — availability zones, scaling policy, backup retention, network topology — belong to Bolt, not to you.
You do not get isolated Kubernetes with your own namespace. You do not get a Postgres instance with backups you restore on your own schedule. You do not get Valkey, MinIO, or Grafana observability. You do not get GitOps — a deployment is not a policy-controlled pipeline triggered by a signed merge. You do not get a staging environment that is a true mirror of production.
When something breaks in production, "check the monitoring" is not an option if there is no monitoring in your control. "Roll back the deploy" is not a policy-enforced action if there is no GitOps state to revert.
Every launch.ist project runs on isolated Kubernetes from day one. Your own namespace or dedicated cluster. Postgres, Valkey, MinIO, Grafana, TLS, backups. Push to main and it deploys via GitOps. Staging is a real environment. The observability tells you what broke before your users do. From $59/month.
No human accountability
Bolt generates the code. No human reviewed it in a technical-accountability sense. No engineer's name is on the merge. If something breaks in production in a way that causes real harm — data loss, a security incident, a checkout flow that fails at scale — the trail from "what is deployed" to "who is accountable" ends at "the AI generated it."
launch.ist puts a human name on every merge. A named engineer reviews the agent's work, the provenance trail, and the verification results. They approve or they send it back. Their name is in the trail at /launches/<date>/<sha>. You can ask them a question. When something breaks later, the trail shows what was checked and who took responsibility for it.
"The AI generated it" is not an answer an investor or a regulator will accept. Agents are our instruments. Humans own the outcome. That distinction is the whole product.
Side by side
Publicly documented behavior as of June 2026. We re-check quarterly. If something here is wrong, tell us and we'll correct it.
launch.ist cites sources for every claim; Bolt does not. launch.ist pins library versions on output; Bolt uses caret ranges by default (in our June 2026 testing). launch.ist generates a test suite and a CI gate before merging; Bolt does not (agentic error-fixing, not test generation). launch.ist runs CVE and license checks on dependencies; Bolt does not. A human engineer signs the work at launch.ist; at Bolt, no one does.
launch.ist gives you isolated Kubernetes in your own namespace; Bolt gives you Bolt-managed hosting. launch.ist includes CI/CD and GitOps, staging plus production environments, and a provenance trail you can re-run; Bolt includes none of these. launch.ist supports a native branch, PR, and review workflow; Bolt offers a GitHub integration only, where review happens in GitHub. launch.ist keeps an immutable audit trail; Bolt does not. Production infrastructure you control comes from $59/month at launch.ist; with Bolt you get a custom domain, but not the underlying infrastructure.
There is one row Bolt wins: full-stack in-browser prototyping with hosting. launch.ist does not do that — it runs locally or via MCP. For full-stack prototyping that runs in a browser and ships to managed hosting in one flow, with zero local setup, Bolt is better than us. We are built for the moment after that row stops being the most important one.
FAQ
We validated our concept in Bolt and now we want to ship it. What does the handoff look like? We review the Bolt-exported codebase, identify what is structurally sound and what needs to be rebuilt for production, and propose a plan. Some Bolt-originated code is worth keeping after a verification pass. Some is worth rebuilding from the architecture up. We'll tell you which and why before you commit to anything.
Can I use Bolt for prototyping and launch.ist for production? Yes. This is a reasonable workflow. Prototype in Bolt to validate the concept, then bring the output through the launch.ist developer agent before it merges to your production branch. The agent will verify the output, add tests, check dependencies, and surface a signed diff. The designer agent can reconcile any components against your design system.
Bolt runs in the browser — is that actually worse than running locally? For prototyping: no, it's convenient. For production: the difference is that a production environment needs to behave deterministically, be observable, be recoverable from failure, and be isolated from other tenants. A browser sandbox and an isolated Kubernetes namespace are different environments. The sandbox is fine for proving an idea. The namespace is what holds when the idea becomes a product.
Doesn't Bolt support deployment to real hosting? Yes. Bolt Hosting is real hosting — not a browser sandbox. What it does not include is CI/CD, GitOps, a staging environment, observability you control, or backups on your own schedule. "Deployed" and "production-ready" are not the same thing. The distinction matters the first night something goes wrong.
Isn't launch.ist just slower and more expensive? Slower to first running code: yes. More expensive than a free prototype tool: yes. The relevant comparison is not the cost of prototyping — it is the cost of a production incident, a security audit, or a rebuild when the prototype can't hold the load. The time cost of rigor is front-loaded. The time cost of skipping it compounds. We don't compete on speed. We compete on what you have when the speed stops mattering and the accountability starts.