A Bolt prompt is written in two passes
Bolt is not a generic chat: it generates code, runs it in the browser and shows you the diff of every change. That changes how you talk to it.
First message: the whole spec. What the app is, who it is for, which screens, what data, which stack, and what is out of v1. This message fixes the architecture, and it is the only moment when changing your mind is cheap.
Later messages: one change each. Name the screen or file, the current behaviour and the expected one. Small requests produce small diffs, and a small diff can be reviewed in ten seconds or thrown away without dragging half the app with it.
How to spend fewer tokens without building less
- Decide before generating. Anything missing from the spec gets decided during the build, and you pay for that in iterations.
- Group by screen, not by task type. "Fix the colours and add login and change the database" is three diffs in one.
- Attach the visual reference. One screenshot of the style you want saves three rounds of "make it cleaner".
- Never ask it to "improve everything". That is the fastest way to break files that were working.
- State the interface language. If you do not, half the labels come back in English.
What to include in the first prompt
| Block | Example of what it should say |
|---|---|
| Scope | "This version only handles bookings; payments and reminders are out." |
| Screens | List, detail, booking, owner dashboard — in that priority order. |
| Data | Tables, fields and who is allowed to see them. |
| Stack and hosting | React with Tailwind, Bolt's built-in backend, or Supabase if this will grow. |
| Criteria | What a real user must be able to do before you call it done. |
One-line prompt vs structured prompt
To see the full prompt with examples, read the guide to writing a Bolt.new prompt.
When Bolt is not the right tool
Bolt is excellent for prototypes and apps with standard logic. If your product depends on background jobs, third-party integrations or fine-grained performance work, you will end up in an editor with your own repository. The Bolt vs Cursor comparison draws that line, and the Inputo wizard recommends a stack for your specific case.
Keep going with the generator
Frequently asked questions
What should I type in the first message of Bolt.new?
The complete spec: what the app is, who it is for, which screens, what data is stored, which stack, and what is out of scope. Bolt decides the architecture in that message, so that is when being specific pays off.
How do I stop Bolt.new burning tokens?
Decide before generating and send one change per message. Bundling three different screens into one request forces more generations and produces diffs you have to unwind.
Why does Bolt give me a different app than I imagined?
Because everything unspecified was decided while building. It usually shows up in the interface language, permissions, screen order and form fields.
Can I use the same prompt in Bolt and Lovable?
Yes. A structured prompt describes your product, not the tool. Paste the same one into both and compare which gets you something showable faster.
Can Bolt build an app with payments?
For the prototype flow, yes; to take real money, connect a payment provider (Stripe and similar) with your own keys and test the flow carefully. It is worth stating in the spec.
Is this generator free?
Yes: free, no signup, up to 8 prompts per hour. The seven-step wizard for the full plan also starts free.