By Maciej Pyrc, who maintains Hype Stack.Published .
Nobody leaves Bolt because the first hour was bad. They leave at the fifth fix attempt on the same bug, or the day the project needs a backend, a repository and a deploy that are not a browser tab.
Bolt.new puts a full Node environment inside your browser, built on StackBlitz's WebContainers, and lets an agent write the app while you watch. You can open any file, run commands, and pick the framework. For a first version that is a very good deal, and the people searching for a bolt new alternative usually agree. What they disagree with is a specific moment that came later.
Read enough threads from people on their way out and the reasons sort into four: tokens spent on fix loops, a project that has outgrown the in-browser environment, auth and backend wiring that keeps breaking, and code that needs to live in a real repository with a deploy you control. Each one has a different best alternative. This page takes them in that order, and says plainly which one ends with us.
Four routes off Bolt
If you mostly want another builder, Bolt vs Lovable covers the choice most people shortlist, and Base44 alternative and Replit alternative cover the platforms that bundle hosting. The rest of this page is for the other three routes.
"Every fix costs tokens and breaks something else"
This is the complaint that shows up first, and the mechanism is simple. Each turn, the agent reads a large part of the project back into context before it changes anything. On a small app that is cheap. On an app with forty components, the progress notes it wrote for itself, and a Supabase client in six places, every retry re-reads all of it. A fix that introduces a second bug turns into a loop where you pay for the same reading over and over.
Before leaving, one thing is worth trying inside Bolt: stop asking it to "fix the error". Paste the exact message, name the one file, and ask for a plan before a change. Deleting the stale notes and unused files it left behind also shrinks what every retry has to read.
If the loops continue, the alternative depends on what you are paying for. If it is the tokens, bolt.diy is the open-source version of Bolt, kept up by its own community of maintainers and not by us. You run it yourself, plug in any model provider's API key, and pay that provider directly. It is the closest thing to Bolt without Bolt's meter, and it keeps Bolt's architecture, so it also keeps the context ceiling. If the loops are the problem rather than their price, a coding agent in your own editor is the better move, which is the next section.
"The project got too big for the browser"
Somewhere past the first hundred or so prompts, people report the same three things: the agent forgets conventions it set up earlier, rewrites files you did not ask it to touch, and a rollback restores the code while the database changes stay where they were. Nothing here is Bolt being careless. A browser tab holds the whole environment, and the agent has to hold the whole project, and both have a size where they stop being comfortable.
A local coding agent such as Claude Code, Cursor or Codex works differently. It searches the repository and opens the
files it needs instead of carrying all of them, git shows every line it changed, and a bad change is one git restore
away. The catch is that an agent in an empty or inconsistent repo invents structure as it goes, which is the drift you
were trying to escape. It needs a codebase with conventions it can read: where routes go, how a query is written, which
rules file to follow.
"Auth and the backend never quite work"
Bolt can give you a database now, its own Postgres with email and Google sign-in, or a Supabase project you connect. Either gets a login screen working in the preview. The failures arrive at the edges: sign-in that works in the preview and loops after deploy because the callback URLs still point at the preview host, an API key that ended up in client code, row-level security switched off so any signed-in user can read any row, edge functions that need Docker to deploy from anywhere else.
Check these before you move anything
- Where the data livesBolt's own database or your Supabase project. Row data exports from Bolt's Tables view; check whether yours can be claimed into a Supabase account you own before you plan the move.
- Every secret in the frontendSearch the export for API keys. Anything that reached the browser bundle should be rotated, not moved.
- Auth redirect URLsList every callback and allowed origin. The new app needs its own, and stale preview URLs are the usual loop.
- What the platform did quietlyEmails on signup, password reset templates, role checks. Each one is a line you now own.
Getting the data out is the step that cannot be redone later, so it goes first.
Rebuilding auth with a prompt in a new tool tends to reproduce the same bugs, because the agent is solving the same problem from scratch again. The cheaper route is to start from auth that already exists and was tested before you arrived.
"I want it in a real repo, with git and a deploy I control"
Bolt has a GitHub integration, and it is worth turning on today if you have not. It is not the same as working in a repository, though. Bolt's version history and git history are separate things, a second developer still wants pull requests and CI, and a deploy you run yourself means picking the host, the database and the environment variables.
This is the route that ends with us. Hype Stack is a template you install on your own machine, with the parts Bolt's agent kept rewriting already in it as source files.
From a Bolt export to a repository you own
Export the code and the data
Download the project or push it to GitHub. Export the tables. This is the spec for everything after.
Scaffold the template
npx @hype-stack/cli template better-studio gives you React with TanStack Router, a Hono backend on Postgres, and the packs installed.
Port the schema
Add your tables to the Prisma schema next to the ones that ship, migrate, then import the export.
Rebuild the screens with your agent
Point Claude Code or Cursor at the exported components. It rewrites them against the typed SDK, inside the rules files and MCP server the template ships.
Deploy it yourself
npx @hype-stack/cli deploy web puts the frontend, admin app, backend, Postgres and Valkey on Fly.io or Railway.
What arrives with Better Studio: the SaaS starter on Better Auth, with sign-in, organizations, roles, invitations and an
admin app; Stripe subscriptions and checkout with webhook handling and a revenue widget in the admin app; and the Glass
layout. What you write yourself is the product: the screens and rules your users came for, written by your agent into a
repository where pnpm test, pnpm typecheck and pnpm lint already run.
The gap is real and worth saying in its own paragraph. There is no chat box, no preview tab and no hosting. Your first hour is slower than Bolt's first five minutes. The frontend is React with TanStack Router and the backend is Hono, so a Next.js app from Bolt is a port of the screens, not a copy. The core template is MIT, and the starter, billing and layout packs are paid.
Where Bolt still wins
Bolt is the better tool when you are prototyping, when you want to learn a stack you have never used, or when nothing can be installed on the machine in front of you. Watching an app appear with the files in view teaches more than a tutorial does, and a weekend experiment does not need organizations, a migration history or a deploy pipeline. If the idea is still unproven, stay. Turn on GitHub sync, keep the data in a place you can export, and decide when the app has users.
For the builder side of the field, see Lovable alternative and v0 alternative. The template and packs below are the own-the-code route, with the command that installs them.