The idea underneath all six
A build prompt is a brief. Picture handing the job to a fast, capable contractor who has never met you, has none of your context and will make a reasonable-sounding decision about anything you leave unsaid.
That tells you to name your domain, to say who will use the thing, and to be specific about the few decisions you care about, while leaving the rest open on purpose.
1. Name the domain, not the category
Categories are generic; domains carry vocabulary, fields and expectations. Naming the domain gets you the right defaults, and defaults are most of a first version.
Before
“Build a management app.”
After
“Build a tool for a dental practice front desk: book a patient into a slot, see today at a glance, mark arrivals and no-shows, and move an appointment to a new time.”
The second version gets you patient names, appointment lengths and a day view without asking. The first gets you a generic list with a status field.
2. List the actions, not the adjectives
Descriptions of quality produce nothing specific. Verbs produce interface.
Before
“Build a powerful, intuitive, modern expense tracker with a great user experience.”
After
“Build an expense tracker where I log an expense with an amount, category, date and an optional photo of the receipt, see a monthly total against a budget per category, filter by date range, and export a month as CSV.”
Every clause in the second version becomes something you can click. None of the adjectives in the first become anything at all.
3. Say what should be true, not how to do it
Implementation instructions limit the solution to what you happened to think of. Stating the requirement lets it be solved properly.
Before
“Add a function that strips dashes and spaces from the phone number field.”
After
“I should be able to find a customer by phone number however it was typed, so searching 5551234567 finds a record saved as (555) 123-4567.”
The second version also covers parentheses, a leading country code and the search box you forgot about.
4. Say where the data lives
An app that forgets everything on reload is the most common first-version disappointment, and one clause prevents it. Say whether the data is yours alone or something visitors send you.
Before
“Build a reading list app.”
After
“Build a reading list app where I add books with an author and a status, saved to my account so they are still there when I come back on another device.”
For things visitors submit, say “send it to my inbox with a form”: on a published Veloxa Build site each submission reaches the site's inbox, and visitors need no account. A list that every visitor reads and writes is not available yet.
5. Give the look a direction in two or three words
Two or three words set a coherent direction; a paragraph of styling instructions produces a design that is following orders rather than making sense.
Before
“Make it look really professional and clean and modern with nice colors and good typography and a premium feel.”
After
“Make it calm and editorial: lots of white space, one accent color, generous line height.”
If you have brand colors, give the hex codes. If you have a logo, attach it. Otherwise leave the palette open: “warmer” is easier to say once you can see something.
6. Ask for one coherent thing per turn
A turn with six unrelated changes gives you six things to re-test, and no clean way to undo only the one that went wrong.
Before
“Add CSV export, fix the date format, make the sidebar collapsible, add dark mode, change the font and add a search box.”
After
“In the transactions table: show dates as 12 Mar 2026 instead of 03/12/2026, and add a search box above the table that filters rows as I type.”
The other four requests are still worth making. Three more turns take less time than untangling one turn that did six things.
A template you can fill in
This covers all six patterns in four lines. Fill in the brackets and delete what does not apply.
Build a [thing] for [who uses it, in what setting]. They need to [action one], [action two] and [action three]. Save data to [my account / my inbox, through a form visitors fill in]. Make it [two or three words of tone], and make sure it works well on a phone.
That is enough for a first version of almost anything. Everything after it is better said in front of a running app than guessed in advance. For ready-made prompts by kind of business, see the starter prompts.
Prompts for the second turn onwards
Follow-ups correct one difference between what exists and what you meant. Three habits help.
- Point instead of locating. Turn on click-to-edit, click the element and describe the change.
- Describe the symptom, not your diagnosis. “The total does not update when I delete a row” beats “the delete handler is broken”, because your diagnosis might be wrong.
- Say what to leave alone when it matters. “Change only the checkout dialog. Do not touch the gear list.”
What is not worth putting in a prompt
A few habits carried over from chat assistants add length without adding results.
- Role-play preambles. “You are a world-class senior engineer” does nothing here.
- Things that are already automatic. Veloxa Build already checks that the page runs after every change and gives apps an icon and an installable manifest.
- A different stack. Veloxa Build writes HTML, CSS and JavaScript and wires apps to its built-in sign-in, storage and database. Asking for another framework costs you the parts that are already connected.