Short answer: Bolt.new runs a real dev environment in your browser, so it wants a technical brief plus a numbered build order, not a conversation. Name the stack (React + Vite + Tailwind), the screens, the data model and the files you expect. Keep each message tight: Bolt has a token budget, and a wall of text or an oversized rebuild can eat it. Ask for one step at a time, check what it built, then ask for the next.
Not tried it yet? Open Bolt.new — that is our referral link; your price does not change.
What Bolt.new actually does well
Bolt spins up a Node environment in a browser sandbox (WebContainer), scaffolds a project, installs dependencies, runs the dev server and shows you the code. It is the tool for people who want to see what was built: diffs, files, terminal output, errors.
That power has a price: Bolt is paying for tokens every time it reads your project. Big prompts and big rebuilds cost more than small, precise instructions — and a broken build costs even more, because fixing it is another message.
Why most Bolt prompts fail
Three patterns, all of them expensive:
- Everything in one giant message. Bolt tries to build the entire app in one turn, hits the token ceiling mid-build, and leaves you with a half-wired project and a compile error.
- No stack declared. It picks its own dependencies, and every extra library is more surface for build errors later.
- Backend requests in the first message. A custom server, a database and payments cannot all be scaffolded in a WebContainer in one shot. Ask for the front end with local data first, then connect a real backend.
The structure Bolt responds to
| Block | Why Bolt needs it |
|---|---|
| Project + stack | React, Vite, Tailwind, TypeScript or JS. Explicit stack = fewer dependencies = fewer build failures. |
| Screens | A route list. Bolt generates pages from routes, so name the routes you want. |
| Data | Shape of the objects and where they live at first (localStorage or a Supabase table). |
| Files | The structure you expect: src/pages, src/components, src/lib. Predictable structure survives later edits. |
| Build order | Numbered steps you will send one by one. This is the block that saves your token budget. |
| Constraints | "No extra dependencies", "no backend yet", "keep components under 200 lines", "run the build after each step". |
Build a full SaaS for freelance invoices with login, Stripe payments, an admin panel, email sending and a database. Make it look professional.Prompt that builds cleanly
Build a web app called InvoiceTidy for freelancers to create and track invoices. Use React + Vite + TypeScript + Tailwind. No extra dependencies beyond that.
Step 0 (scaffold) — do only this now:
- Vite React + TS project, Tailwind configured, simple dark theme with one accent colour.
- React Router with these routes: /login, /invoices, /invoices/new, /invoices/:id, /settings.
- Folder structure: src/pages, src/components, src/lib, src/types.
- A shared layout with a top bar and a left sidebar; responsive down to 360px.
Data (types only for now, stored in localStorage behind a small repository in src/lib/store.ts):
- Invoice: id, clientName, clientEmail, number, issueDate, dueDate, currency, status ('draft' | 'sent' | 'paid'), lineItems: {description, quantity, unitPrice}[], notes
- Client: id, name, email, taxId
Later steps (do not do them yet, just tell me when step 0 is done):
1. Invoices list with status filter and search.
2. New invoice form with dynamic line items and live totals.
3. Invoice detail with a print-friendly layout.
4. Settings: business name, logo, default currency and tax rate.
Rules:
- Run the build after each step and fix any TypeScript errors before reporting back.
- Keep each component under 200 lines.
- No backend, no auth library, no payment provider yet — those come after the front end works.
- Ask me before adding any dependency.
Bolt-specific rules
- Send step 0 alone. Scaffold, layout, routes. Confirm it runs before asking for features.
- One feature per message. Small diffs, small token cost, easy to undo.
- Forbid surprise dependencies. Every package it adds can break the build — and fixing a build is a paid message.
- No backend in message one. Front end with local data first; Supabase, a real API or payments later.
- Ask it to run the build. "Fix all build errors before answering" turns a broken project into a working one in the same message.
- Export your code. Bolt gives you the files; keep a copy in a Git repository so an experiment never destroys the last working version.
Checklist before you press send
- Is your stack explicit and minimal?
- Does step 0 stop before the first real feature?
- Are the routes named?
- Are the data types written out?
- Have you said what not to add yet?
- Is there an instruction to run the build and fix errors?
Or let Inputo write it for you
Inputo asks you the questions you did not know you had to answer — one screen at a time — and gives you back a complete, structured prompt. Pick Bolt as your tool and the prompt comes with the build order and the constraints already in it, ready to paste.
Free to start; the full prompt is €5/month, or €5 once for 7 days if you prefer a one-off payment.
That is a referral link: you get Bolt, we may earn a commission. Your price does not change.
Frequently asked questions
Is Bolt.new free?
There is a free tier with a daily token allowance, and paid plans on top. The practical difference is how efficiently you spend tokens: a precise prompt that works first time is worth more than a free plan with ten failed builds.
Bolt or Lovable for a non-technical founder?
Lovable is friendlier: chat, polished UI, one-click deploy. Bolt gives you more control and shows the code. If you have never built anything, start with Lovable; if you want to see and keep the code, Bolt.
Why does Bolt run out of tokens so fast?
Usually because of huge messages and full rebuilds. Split the work into numbered steps, keep the file structure predictable, and avoid "rebuild the whole app with..." requests. Our full Lovable vs Bolt comparison covers the trade-offs in detail.