TL;DR: Bolt.new prompts carry two loads at once: the product decisions a chat prompt never has to make, and the cost of everything the agent must read to act. This page follows Bolt's own published prompting guidance, adds 21 copy-paste templates by build stage, and marks where the tool stops.
Is it still called bolt.new, and did anything move?
The address did not change, but the name presented to you did. The product brands itself as Bolt; the homepage title reads "Bolt AI builder: Websites, apps & prototypes", and the help centre's own intro page describes it as "an AI-powered builder for websites, web apps, and mobile apps". You still get there by typing bolt.new, and the documentation is still at support.bolt.new, the same host StackBlitz has pointed at from its public repository since 2024. Nothing moved, and that negative result is worth as much as a rename would be: old links and old bookmarks still resolve.
One thing has gone quiet, and it is a useful staleness tell. The MIT-licensed stackblitz/bolt.new repository is still public and not archived, but its most recent push was December 2024. A guide leaning on bolt.new is open source describes a snapshot, not the product you prompt today.
What changed is the product underneath the name. Bolt now ships its own database, hosting and domains under Bolt Cloud, so any guide that treats Supabase as the only route to a backend is describing the 2024 product. Supabase is still supported and still selectable when you start a project, but it is now the alternative rather than the route.
What does Bolt scaffold first, and what does it assume?
It assumes JavaScript, and it decides about the database rather than committing either way, which places it between the two tools it gets compared against.
Our Lovable prompt templates describe a frontend-first flow where you defer the database until data has to survive a refresh. Base44 inverts that and generates schema, auth and APIs from the first message. Bolt does neither by default. Its database documentation says it "creates a database automatically if your project needs one, or if you explicitly ask Bolt to create a database or a database-related feature", and it publishes the opt-out as a literal sentence you can paste: "Don't use a database, I want to use local storage for this app."
So the decision is real, it is yours, and it is made by inference if you say nothing. That is the most important thing to hold in your head when you write the first prompt.
The stack assumption is harder. Bolt runs your project inside your browser tab on WebContainers, which StackBlitz describes as "a browser-based runtime for executing Node.js applications and operating system commands, entirely inside your browser tab". Its supported technologies page states the consequence bluntly: "Bolt only supports JavaScript-based backends, so languages such as PHP or Python aren’t compatible." Node.js is the backend, and a Python service has to live elsewhere and be called over HTTP.
Why does a Bolt.new prompt cost differently from a Lovable or Base44 one?
Because you are not billed per message. You are billed for how much of your project the agent had to read, and Bolt says so directly: "Most of your token usage comes from Bolt reading, understanding, and syncing your project files, so larger projects use more tokens per message."
That changes what a good prompt looks like. In a credit-per-message tool a long prompt and a short one cost the same, so you write long. In Bolt the expensive part is the context your prompt drags along, so scoping is not politeness. It is the price.
Three consequences follow, all documented:
- Buttons are free, prompts are not. Bolt's token guidance is explicit: "Clicking an on-screen button or action doesn't use tokens, but prompting Bolt does." Publishing, reverting and the security audit all have buttons. Asking for them in chat is a paid version of a free action.
- File size is a prompting variable. Bolt tells you to split large files, and its own two pages disagree on the threshold. The context guide asks Bolt to "list every file over 700 lines"; the troubleshooting guide says "If a file Bolt is editing is around 500 lines or more, request a refactor into smaller, more focused files." Both are Bolt's. Take 500 as the cautious number.
- Clearing context is a move, not a reset button. After a clear, Bolt "still has access to your codebase and files, but it evaluates them as if seeing them for the first time". Anything established conversationally is gone, so what must survive belongs in project knowledge or an
agents.mdfile, both of which Bolt reads automatically.
What does Bolt's own prompting guidance say?
More than most people cite. Bolt publishes a planning framework, quick tips and a prompt-improvement tool, and the framework is worth teaching as theirs rather than inventing one. Its project lifecycle guide asks five questions before your first prompt. Answer them in writing and you have most of a first prompt already.
| Bolt's question | What it settles |
|---|---|
| What do you want to build? | The category: website, web app, or mobile app |
| Who is it for? | The user whose needs break ties later |
| What features does it have? | The list of things a user can do |
| What look and feel do you want? | Aesthetic direction, or reference images |
| How will users access it? | Browser or installed app, which changes the structure |
Its prompting page adds tips that read like a house style. "Start with the application architecture, including your choice of tools, frameworks, and so on." Add components one at a time. "Be explicit about what should and shouldn't change." And the one worth taping to a monitor: "Don't expect the LLM to have common sense."
There is also an Enhance prompt control that interviews you with guided questions and rewrites your prompt from the answers. It earns its keep on a first prompt and wastes your time on a one-line change, because the rewrite adds detail you then have to prune.
Plan Mode, Build Mode, Standard or Max: which are you in?
Two switches, not one, doing different jobs. Most published Bolt advice mentions neither.
| Switch | Options | What changes |
|---|---|---|
| Mode | Plan Mode, Build Mode | Whether the prompt writes files at all |
| Agent | Standard, Max | How much reasoning is applied, and what it costs |
Bolt describes Plan Mode as a way to "Chat with Bolt to get help without immediately generating code", and it is not a lightweight chat: "Every discussion message includes your project codebase for context-aware responses, as well as the most recent messages." It can search the web and offers quick action buttons such as Implement this plan that hand the result to Build Mode. Bolt's stated reason to use it: you can "explore ideas safely, save tokens by avoiding unnecessary code exchanges".
The agent picker has a direct prompting consequence. Bolt says Max "is also more responsive to detailed prompts: if you describe a specific problem and ask it to think carefully, it uses deeper reasoning in that area." The same prompt is therefore not the same prompt on both: a long, carefully reasoned instruction is partly wasted on Standard and partly what unlocks Max. Note also that "Only Standard is available on the free plan."
The 21 templates below are ours. The technique underneath is Bolt's, from the pages listed at the end, and everything in quotation marks was read on the page it is attributed to. Square brackets are yours to fill.
Stage 1: what goes in the first Bolt.new prompt?
The five planning answers, the stack, and one explicit deferral. This is the one prompt where the project is empty, so the context you drag along is nearly nothing and detail is cheap. It is also the prompt that decides whether you get a database.
Build [app name], a [website / web app / mobile app] for [who uses it].
Users can: [action 1], [action 2], [action 3].
Core screens: [screen 1], [screen 2], [screen 3].
Look and feel: [three adjectives], with [reference site] as the layout reference.
Access: users reach this [in a browser / as an installed mobile app].
Stack: React with [Vite / Next.js], TypeScript, Tailwind.
Data: [create a database / do not create a database, use local state only].
Build the [screen 1] flow end to end first, with realistic sample data.
Do not build [deferred feature] yet.
Architecture-only opener, for when you want to inspect the shell before any feature exists:
Set up the project shell only. Write no feature code.
Framework: [React + Vite]. Routing: [React Router] with routes for [/, /app, /settings].
Styling: Tailwind, with a tokens file for colour, spacing and type scale.
State: [TanStack Query] for server state, [Zustand] for local state.
Layout: one folder per feature. No file over 300 lines.
No database in this step.
Show me the file tree and the empty route stubs, then stop.
Mobile opener, which has to say so out loud because the structure differs:
Build a mobile app for [purpose], for [audience]. It must run through Expo
so I can publish to the app stores.
Screens: [screen 1], [screen 2], [screen 3].
Users can [action 1] and [action 2].
Offline: [what the app does with no connection].
Use realistic sample data. No database in this first version.
Stage 2: how do you prompt the data model, or refuse one?
State the shape before any code exists, or state that you want no database. Both are prompts. The refusal below is Bolt's own wording, extended with the part it omits: a way to get the data back out.
Add persistence for [feature]. Before writing code, list every table you plan
to create with each column, its type and its nullability, and wait for me.
Rules:
- A [record] belongs to exactly one [owner]
- [field] is unique per [owner]
- Deleting an [owner] [cascades / is blocked while records exist]
- Every table has created_at and updated_at
- No table is readable without an authenticated user
Do not modify any existing table. Do not touch the UI in this step.
Don't use a database, I want to use local storage for this app.
Keep all state in the browser. Add an export-to-JSON and an import-from-JSON
control so a user can move their own data between devices.
Additive change, for after real rows exist:
Add [field] to [table] as an additive change only: new nullable column with a
default, plus a backfill for existing rows. Do not rename or drop anything.
List the components that read this table before you edit any of them.
Stage 3: how do you prompt auth and access rules?
By writing the rules as sentences and asking to see the policies before they apply. Bolt provisions auth and permissions for you, and its database security page names the failure this prevents: "a missing row-level security (RLS) policy or a permission that's too open".
Add email-and-password authentication with these rules, stated explicitly:
- Signed-out visitors see: [public pages] only
- Signed-in users see and edit: only rows where owner_id equals their user id
- [Admin role] can [scope], and can never delete [thing]
- Signing out ends the session
- A failed sign-in must not reveal whether an email has an account
Enable row-level security on every table and show me each policy as SQL
before you apply it.
List every table in this project. For each, show the row-level security
policies in force, as a table with columns: table, operation, who it allows,
and the condition. Flag any policy that evaluates to true for everyone.
Change nothing yet.
Stage 4: how do you change one screen without touching the rest?
By naming the boundary mechanically, not politely. In Code view, right-click a file and choose Target file to limit Bolt to it, or Lock file and Lock all to exclude a file or directory. Those settings outlive the prompt. You can also tag a file with @, or click Select to point at an element in the preview. Use all three.
Change only [file path]. Do not edit any other file.
On [screen name]: [precise change].
Keep the existing [component / route / data fetch] exactly as it is.
If this change requires touching another file, stop and tell me which file
and why, instead of editing it.
For @[file], add the four states this screen is missing:
- Loading: a skeleton matching the final layout, not a spinner
- Empty: one sentence saying what will appear here, plus the primary action
- Error: what failed, what to try next, and a retry control
- Partial: what to show when [field] is missing on some rows
Do not change the success state.
[Element selected in the preview] Change this element only: [spacing / copy /
alignment / tap behaviour]. Do not restyle the parent container, and do not
change this component's props or the data it receives.
Stage 5: how do you prompt an integration?
By checking the current API before writing against a remembered one. Plan Mode can search the web, which is the right tool for a third-party surface that moves. One documented trap on payments: "Existing custom Stripe implementations cannot migrate to this built-in integration but will continue to function."
Read the payments page carefully, because it contradicts itself within four paragraphs. One line says "The integration requires Supabase as your database provider"; another says you can add Stripe "to any Bolt project that uses Bolt Database or Supabase for its database, authentication, and edge functions." Both are Bolt's, same page, 27 August 2026. Confirm which applies before building a checkout around it.
Add Stripe checkout for a single [one-time purchase / monthly subscription]
called [name].
- Keys live in project secrets, never in client code
- All price and entitlement checks happen server-side
- Handle the webhook events for success, failure and cancellation
- On success, set [field] on the signed-in user's row
List the test-mode steps I should run before we go near live keys.
In Plan Mode: I want to integrate [API name] for [purpose]. Check the current
documentation and tell me the auth method, the endpoints we need, the rate
limit, and the failure modes. Do not write code yet.
Stage 6: how do you prompt for a look you actually want?
By separating the visual layer from everything else in the sentence itself, and asking for tokens before screens. An unfenced design prompt is the commonest source of accidental regressions, because make it look better touches every file that renders anything.
Restyle the visual layer of [screen] only. Keep every route, prop and query
identical.
Direction: [three adjectives], referencing [site], primary colour [hex],
type [font pairing].
Rules: one accent colour, an 8px spacing scale, at most two type sizes per
screen, interactive targets at least 44px, WCAG AA contrast.
Show me the tokens file first, before you touch any component.
Scan every screen and list where the design drifts from the tokens file:
hardcoded colours, one-off spacing values, font sizes outside the scale.
Output a table of file, line, and the token it should use. Change nothing yet.
Stage 7: what do you prompt when the build breaks?
Evidence first, a diagnosis, then the smallest fix. Bolt offers an automatic fix button, and its own token guidance warns against pressing it "over and over, hoping for things to eventually work out". Our debugging prompt set generalises this beyond app builders.
[Paste the exact error text and the browser console output]
Reproduce path: [what I clicked, in order].
Expected: [x]. Actual: [y]. It last worked [when].
Diagnose the root cause before changing anything. Name the file at fault and
explain why, then propose the smallest fix.
Don't fix this yet. Add detailed debug logging through [the failing path]:
entry and exit of each function, the shape of the data at each hop, and the
branch taken. Then tell me which log lines to send back to you.
Three fixes have not changed the error. Stop fixing. In Plan Mode, list every
assumption you have made about why this fails, mark which ones you have
actually verified in the code, and name the cheapest test that would rule out
the biggest unverified one.
Stage 8: how do you iterate without regressions?
By fencing what must not move, and managing context deliberately rather than letting it fill. The handoff prompt below matters more than it looks: after a clear, the agent has your files but none of your reasoning, so a written summary is all that survives.
Add [new feature].
Untouchable: [file / route / flow 1], [file / route / flow 2], and the
database schema.
Before you start, list the files you intend to change and wait for me.
After you finish, list what changed and what you verified still works.
Summarise this project for someone who has never seen it: purpose, users,
routes, data model, integrations, and the three things most likely to break.
Write it to README.md, under 400 words.
Scan the project and list every file over 500 lines: path, line count, and
what it does, longest first. Don't change anything yet.
Run the summary prompt, clear the context, then open the next task by asking Bolt to read README.md first. That sequence is Bolt's own recommendation, and it separates a project that gets harder to prompt from one that does not.
Where does Bolt stop and real engineering start?
At the point where the app looks finished. Generated apps reach a convincing preview long before a safe one, and Bolt is unusually honest about that gap.
It ships a project security audit covering six categories: who can see and change your data, what the app exposes publicly, how sign-in works, ways the app can be misused, what input it accepts, and where keys are stored. Bolt's description of the first is the whole risk in one line: it "looks for ways one person could see, change, or delete information that isn't theirs." The audit is on paid plans and capped at "up to 30 security audits per day"; a lighter database-only check is on all plans.
Three further limits are worth knowing before promising a launch date.
- Version history does not restore data. Bolt's database docs warn that it "currently does not support database restores", and that "Restoring to an earlier project version will not change your current databases." Code and data roll back on different clocks.
- The runtime is the ceiling. No Python, no PHP, no native binaries in the backend. If what you need is a JavaScript library away, you are fine. If it is a Python library away, you are building a second service.
- A passing audit is not a review. Anything touching logins, payments or personal data still needs a human who can read the generated code, as with every tool in this category, including our v0 UI prompt guide.
What does the Bolt free plan actually let you do?
Enough to finish a small project, not enough to iterate carelessly. Bolt's pricing page lists the free plan with "300K tokens daily limit" and "1M tokens per month", public and private projects, a "10MB file upload limit", "Unlimited databases", hosting "Up to 333k web requests", and "Bolt branding on websites".
Two details matter more than those numbers: only the Standard agent is available free, and the full project security audit is paid, though the database-level check is not. Free-plan tokens do not roll over. All checked 27 August 2026.
Stop rewriting prompts. Start shipping.
Works with ChatGPT, Claude, Gemini, Grok, Midjourney, Ideogram, Veo3 & Kling. 5.0★ on the Chrome Web Store.
Create An AccountDoes a prompt library help when Bolt already ships one?
Yes, for a narrower reason than usual, and the overlap deserves a straight answer. Bolt has its own Prompt Library, with "Built-in prompts Bolt provides for common development tasks like SEO, accessibility, dark mode implementation, and error handling", plus custom prompts you save and call with a slash command. It also has Skills, "reusable instructions that teach Bolt how to handle specific scenarios", on all plans and importable from GitHub. If your prompting happens entirely inside Bolt, use them.
Two gaps are documented rather than alleged. Bolt's own page states that "Custom prompts aren't shared with other members of a team workspace by default", and gives the workaround as sending a teammate the prompt text to add themselves. And a Bolt library only helps inside Bolt. Most people building this way also prompt a chat model for copy, a research tool for the spec and an image model for assets, and none of those read it.
That is the honest boundary for us too. We do not build apps. Prompt Architects is a prompt layer: it turns a rough instruction into a structured one and keeps it reusable across every tool you type into, which is the part copy-pasting between tabs never solves. The app still gets built in Bolt.
The Bolt.new build-stage checklist
- Answer Bolt's five planning questions in writing before opening the chatbox.
- Decide the database question in prompt one. Silence is a decision.
- Name the stack, and remember the backend is JavaScript whether you say so or not.
- Use Plan Mode for anything you cannot state in one sentence, including debugging.
- Match the agent to the task, and write longer prompts only where the reasoning is used.
- Fence every change prompt with what must not move, backed by Target file or Lock file.
- Press buttons for publish, revert and security audit. Those are free; prompts are not.
- Split files past 500 lines, delete dead ones, and clear context between features.
- Write the README summary before every context clear.
- Run the security audit before publishing, and read the action items rather than skim them.
Sources and access date
Every Bolt page quoted above was read on 27 August 2026 at support.bolt.new, which publishes an llms.txt index and a plain Markdown twin of every page, so each quote is checkable in one fetch. Allowance figures come from bolt.new/pricing; the WebContainers description from webcontainers.io, published by StackBlitz. Bolt documents no public build API or CLI, and its index links an OpenAPI specification that returned 404 when checked. Prices are omitted here because they change.