Bolt.new, turning one description into a working application

Bolt.new, turning one description into a working application

Bolt.new turns a description into a complete application and runs it immediately, with nothing installed locally. The code executes in the browser through WebContainers, StackBlitz technology that boots a Node environment inside a browser tab. Claude powers code generation, and billing rests on tokens rather than project count.

What separates Bolt from other generators

Most tools in this category generate an interface and leave you with code to run elsewhere. Bolt runs the whole thing in place: it installs dependencies, starts a dev server, and shows a preview and a console. When something breaks, the model sees the error message and fixes the code without you copying a log.

The second difference is scope. A component generator hands you a button or a form. Bolt builds project structure, routes, API calls, and a data layer, so you start from something that runs rather than from a fragment to assemble.

A concrete limitation sits behind that convenience, and it is worth knowing up front. WebContainers boot a Node environment inside the browser, so anything requiring a real operating system is out. Libraries with native components, databases running as a separate process, and tools shelling out to system commands will not work. For a typical web application built on React and HTTP calls that hardly matters, while a project doing server side image processing or running a local database needs a different home.

The third is full file access. You see the project tree, edit any file by hand, and the same preview picks up the change. That sets Bolt apart from tools whose only input is a chat box.

Set expectations early. Bolt is good at standing up a working skeleton in fifteen minutes. It is not good at carrying a mature application through months of development, because the more code there is, the more tokens each fix consumes and the more often the model loses sight of the whole.

Tokens, or how billing actually works

You pay neither per project nor per hour, but for the tokens the model consumes on each change. That is fair billing and unintuitive at the same time, because cost scales with project size rather than task difficulty.

Yearly billing lowers every paid rate, quoted by the vendor as a saving of up to twenty eight percent, so on a tool you intend to keep it is worth pricing straight away.

The mechanism that surprises people most: on every fix the model receives the project context. Changing a button colour in an app of five files costs a fraction of the same change in an app of fifty. That is why the first hour flies and, a week later, the same allowance covers noticeably less.

Three habits genuinely cut consumption. Phrase instructions concretely, naming the file and the expected result. Make small edits, a label or a spacing tweak, by hand in the editor rather than through chat. Start a fresh project when the direction changes, instead of reshaping the old one through more instructions.

What the workflow looks like

You start with a description. The more specifics, the fewer correction rounds.

Build an app for workshop sign-ups.
Stack: React, TypeScript, Tailwind, data in localStorage.
Screens: workshop list with a date filter, sign-up form with email validation,
an admin panel listing attendees with CSV export.
English interface, light theme, rounded cards.

Bolt creates the structure, installs dependencies, and shows a preview. From there you work iteratively, though order matters: settle the data structure and screen flow first, take care of appearance afterwards. The reverse order produces a polished interface that has to be rebuilt once the data model changes.

Once the application makes sense, export it to a repository and move further work into your own editor. Bolt integrates with GitHub and deploys to Netlify or Vercel with one click.

Bolt Cloud and the data layer

The second version of the product added Bolt Cloud, meaning a built in database, authentication, file storage, edge functions, analytics, and hosting. An application with user accounts therefore needs no separate services wired in.

That is convenient at the prototype stage and worth thinking through for production. A built in layer ties the project to one vendor, and moving the data later can cost more than the time saved at the start. If you already know the product will go further, consider connecting Supabase from the beginning, since it stays with you after you leave Bolt.

A simple test helps before deciding: list the data the application will hold a year from now and ask whether it could be exported in reasonable time. If the answer is yes, the built in layer is a safe starting choice. If not, pay the configuration cost now, before customer data lands in that database.

Whichever you choose, mind your keys. Secrets written into frontend code reach the browser, and a generated project has no inherent separation of layers. This is among the most common problems in applications built this way.

Bolt against Lovable, v0, and Replit

The differences show clearest on the same task. A simple panel with a list and a form takes about the same time in any of them, while an application with authentication and several linked screens pulls them apart: Bolt builds the structure and leaves you with code, Lovable delivers a prettier result with less control, and v0 asks you to assemble the whole yourself.

Entry plan prices are close, so the choice rarely comes down to the bill. What decides is whether you want code to keep working on or a finished product to click through.

It is also worth knowing that all these tools generate the same kind of code: correct, conventional, unoptimised. It serves well as a starting point and needs review before anything touching money or personal data goes live.

Writing instructions that do not burn tokens

An effective Bolt instruction looks different from a conversation with an editor assistant. The model knows neither your intent nor the project history beyond what it sees in the files, so the description has to stand on its own.

Three elements lift accuracy noticeably. Name the file or screen the change concerns instead of describing it in general terms. State the expected result in terms of behaviour, not code shape. Say what must not change, because the model happily rebuilds neighbouring fragments along the way.

In src/components/SignUpForm.tsx add phone number validation:
nine digits, spaces allowed, message below the field.
Do not change the form layout or the submission logic.

An instruction in this shape costs several times less than a request along the lines of "fix validation in the form", because the model neither searches the project nor guesses the scope.

Error fixing is a separate matter. When the preview shows an exception, pasting the message often works better than describing the symptom in your own words. The model then gets the exact location in code instead of reconstructing it from prose.

When two consecutive attempts fail to fix the same error, break the loop. A third attempt usually fails too, and each costs the same as the last. It is faster to open the file, read the code, and fix it yourself, or to roll back to an earlier project state and approach it differently.

What Bolt is genuinely good for

It fits four situations. A prototype for a meeting, when a mockup falls short and a clickable app carries the point. An internal tool for a handful of people that nobody wanted to hand build. A starting point for a project whose skeleton takes fifteen minutes instead of two days. Learning, since reading working code with the model's commentary often beats a tutorial.

It does not fit work on an existing large repository, performance sensitive requirements, or features whose correctness has to be proven by tests. There, an assistant wired into your editor such as Cursor makes more sense, because it works on your code instead of generating new code.

Moving out of Bolt into your own project

The moment to move work into a local environment usually arrives earlier than expected. Three signals mark it: the project passes a few dozen files, fixes start breaking things that used to work, or tests become necessary.

The export itself is simple, since what comes out is an ordinary Node project with a package.json. After cloning the repository you install dependencies and start the dev server.

git clone git@github.com:username/my-project.git
cd my-project
npm install
npm run dev

The first steps after the move are worth doing in a set order. Add linter and formatter configuration, because generated code tends to be stylistically inconsistent between files. Review dependencies, since the model will happily pull in a library for one function you would write in ten lines. Check where keys end up and whether calls to external APIs go out from the server.

That last point takes one command to check, before you deploy anything.

grep -rn "API_KEY\|SECRET\|sk-" src/ --include="*.ts*" --include="*.js*"

If anything turns up outside server side files, the key reaches the browser and is public regardless of what the variable is called. Generators happily place calls to external services where the effect shows fastest, meaning inside a component, and that is precisely where they should not sit.

Only then add tests, and not everywhere, just around logic that handles money, deadlines, or permissions. The rest of the generated code is usually presentation, where testing at this stage buys little.

From that point an editor based assistant makes more sense. Bolt did its job, shortening the path from idea to a working skeleton, and further work on a growing repository is a different task calling for a different tool.

Common mistakes

The first is one long prompt describing the entire application in full detail. The model drops part of the requirements, and fixing that costs more tokens than building the app in stages would have.

The second is using chat for things that are faster to change by hand. Editing a label through an instruction is a full context round trip, while the editor does it in a second.

The third is staying in Bolt too long. Once a project passes a few dozen files, work slows and costs rise. Exporting to a repository is the natural next step, not a failure of the tool.

The fourth is deploying without a code review. A generated application usually lacks server side validation, rate limiting, and permission checks, because nobody asked for them.

The fifth is mistaking a prototype for a product in front of a client. An app from Bolt looks finished, so it is easy to promise a delivery date based on what is on screen. The work that remains, permissions, error handling, tests, and performance, often takes longer than the generation did.

The sixth is having no backup. The project lives in a browser, so connect a repository immediately, before a closed tab costs you hours of work.

FAQ

Is Bolt.new free?

The free plan gives a million tokens per month with a three hundred thousand daily cap and needs no card. That covers a few prototypes a month. The Pro plan costs 25 USD and starts at ten million tokens, with unused tokens rolling over into the following month.

The rollover of unused tokens carries a limit that is easy to forget when planning a bigger push. The allowance carries into one further month, staying valid for at most two months in total. Saving tokens for a project a quarter away will not work, because the oldest part of the allowance simply lapses.

Is Bolt's code production ready?

As a starting point yes, as a finished product rarely. Structure and conventions are sound, while server side validation, error handling, and permission checks are usually missing. Anything accepting user data needs a review before launch.

How does Bolt differ from Lovable?

Bolt offers more control over the code and a full in browser environment, Lovable bets on a polished interface and simplicity for non technical users. Entry plans cost about the same, the difference shows in team pricing and in how much work remains on your side.

Can I export the project?

Yes, the project exports to a GitHub repository or downloads as files. It is an ordinary project with a package.json, so any package manager runs it locally and you continue without Bolt.

Why do tokens run out faster than at the start?

Because every fix hands the model the context of a growing project. The same change costs more in an application of fifty files than in one of five. Hence the advice to make small edits by hand and to start a new direction in a new project.

Current plans are listed on bolt.new, and the technology running code in the browser in the WebContainers documentation.