Bolt.new is fast at scaffolding. buildr is fast at the boring part too.

Why Bolt users start shopping around

Bolt.new is honest about what it is: a great scaffolding experience. The trouble is, "scaffolding" is roughly 15% of building a product. The other 85% is everything that happens between "git push" and "somebody pays you for this."

• The deploy is BYO. Bolt happily exports to Netlify or StackBlitz hosting, but the moment you want a real domain, a real DB, a queue, or a cron, you're back to wiring vendors yourself.
• WebContainers are amazing… until they're not. They run in your browser tab. Native modules, heavy build steps, anything Node-only-with-binaries — it gets weird.
• The agent ends at the editor. Once the code is exported, Bolt isn't the one watching your error logs. Nobody is.
• "Bolt + Supabase + Netlify + Resend + ..." The DIY assembly is fine when you're a senior dev. It's a tax when you're not.
• Tokens add up fast. Heavy iteration with Bolt's metered model burns through credits the moment you're rebuilding bigger projects.

What Bolt.new actually nails

Real talk: the WebContainer demo is one of the most impressive bits of engineering on the modern web. There is something magical about watching `npm install` run in your browser. Bolt's prompt-to-code loop is also fast and forgiving — the iteration cycle is short enough to actually feel productive.

If you want a sandbox to try ideas, hand a non-technical co-founder a working interactive thing on a Monday afternoon, or learn React without setting up a dev environment, Bolt is a fine pick.

Bolt's slogan could be "we'll handle the easy 15%." That's not a dig — it's literally what they ship. The remaining 85% is what we exist for.

The wall everybody hits

Production is somebody else's problem

Bolt's built-in deploy is fine for static demos. The moment your app needs a database (real one, with backups), a queue worker, a cron, websockets, file uploads to private storage, scheduled emails or a webhook receiver, you're outside the editor and into the cloud-config wilderness.

buildr's runtime is part of the agent. When you ask buildr "now run this every 4 hours," it adds a Cloudflare Workers Cron Trigger and ships it. When you ask "store user uploads," it provisions an R2 bucket. When you ask "make this real-time," it stands up a Durable Object. No second tool, no second bill.

Operations is also somebody else's problem

Once your Bolt-exported app is in production, who runs `wrangler tail` to read logs? Who applies the next migration? Who rotates a leaked secret on a Friday at 6 PM? With buildr, the answer is: the agent. You can ask in chat, "checkout error spike at 2 AM, what happened?" and it actually goes and reads the logs. We call it "production from the prompt."

Lock-in shaped like a browser tab

Your Bolt project lives inside StackBlitz's preview environment. You can export, but the agent doesn't follow. With buildr, the codebase is a normal repo on GitHub — Hono, Next.js, Astro, Tauri, your call — and the agent works on that repo whether you're in chat or not.

Side-by-side

Who should use which

Migrating from Bolt to buildr

1. Export your Bolt project to a GitHub repo (the standard "open in StackBlitz → push to GitHub" flow)
2. Connect that repo in buildr's onboarding — the agent reads the codebase
3. Tell it: "deploy this on Cloudflare and add a D1 database for X" — it writes the migration plan, asks before destructive steps
4. If you had Supabase, you can keep it (works fine) or let buildr port to D1
5. Point your domain. The agent now owns the operate loop