How to stop burning credits in Lovable, Bolt and Cursor

If you have used Lovable, Bolt, v0, Cursor or Claude Code for more than an afternoon, you know the pattern. The first screen appears like magic. Then you ask for a change, and another, and another, and the credit counter drops faster than the app improves. By the time it does what you meant, the month's credits are gone, and because most tools bill in US dollars, a weaker rand makes it worse.

The good news: most of those credits are avoidable. They go on correcting guesses, not on building.

Where your credits really go

Every message to an AI builder costs something. The expensive messages are not the big ones; they are the corrections:

• "No, a job can have more than one technician." The tool guessed the data structure, and now it has to rebuild it and every screen that uses it.
• "Clients shouldn't see other clients' jobs." Permissions were never specified, so they were never built.
• "That button broke the invoice page." A change in one place had side effects elsewhere, because the tool did not know how the parts connect.
• "Use rand, not dollars, and South African phone numbers." Small details, each one a separate message.

Each correction is a full round trip, and some trigger a cascade of fixes. Ten corrections can easily cost more than the original build.

Rule 1: decide before you prompt

The single biggest saving is answering the questions the tool would otherwise guess. Before your first prompt, write down:

1. The roles and what each may do, such as "Technicians see only their own jobs and can't delete anything".
2. The tables and fields, including the choices for every status: New, Scheduled, In progress, Waiting for parts, Complete.
3. The links between records: a Job belongs to a Client; an Invoice belongs to a Job.
4. The screens for each role and what is on them.
5. The rules: "A job can't be marked complete without the client's sign-off."
6. Local formats: rand amounts, dates as 29 October 2026, phone numbers as +27.

This page of decisions is your blueprint. It is the same thing a developer would write before starting, and it is what lets the tool get it right the first time.

Rule 2: build in phases, in the right order

App builders work best one step at a time. Asking for "the whole system" in one prompt produces something shallow that needs endless fixing. A reliable order is:

1. Foundation: sign-in, roles and the basic layout.
2. Data: the tables and the screens to add, view and edit each record.
3. Workflows: status changes, approvals, sign-offs.
4. Automations and notifications: reminders, follow-ups, alerts.
5. Dashboard: the numbers that show it is working.
6. Polish: wording, colours, empty states, mobile layout.

Each phase builds on a stable base, so changes in later phases rarely break earlier ones.

Rule 3: use exact names, every time

If your database calls it "job_status" and your prompt says "the state of the job", the tool may create a second field. Pick names once, in your blueprint, and use them in every prompt. The same applies to roles, screens and statuses. Consistency is cheap; confusion is expensive.

Rule 4: one change per prompt, with the reason

"Add a priority field to Jobs (Low, Normal, Urgent) so the office can sort urgent call-outs to the top of the list" is better than "add priority and fix the colours and make the list sortable". One clear change, with its purpose, is easier for the tool to get right and easier for you to check.

Rule 5: test with real examples before you build more

Before moving to the next phase, run three or four real cases from last week through what you have. Catching a wrong assumption in phase 2 costs one prompt. Catching it in phase 6 can cost twenty.

Rule 6: keep secrets out of prompts

Never paste passwords, API keys or bank details into a prompt or a code file. Use each tool's own secure settings for credentials. It is safer, and it avoids the clean-up prompts later.

A quick checklist

• Roles and permissions written down
• Every table, field and status choice decided
• Links between records clear
• Screens listed per role
• Rules and local formats stated
• Build order planned in phases
• Real examples ready to test with
• No secrets in any prompt