Nine out of ten first builds come back looking like a demo someone abandoned. Wrong fields, a broken sort, a login screen that works for nobody. The tool usually gets blamed. The prompt is almost always the culprit.
Here is the uncomfortable part: the people getting clean results from an AI app builder on the first pass are not writing better English. They are writing more like a project manager and less like a customer with a wish. I have reviewed maybe two hundred of these prompts over the past year, and the failures share the same four gaps. Fix those gaps and the hit rate jumps fast.
Why your prompt keeps producing something almost right
You describe a dashboard. It builds a dashboard. Then you open it and the numbers are placeholders, the date range resets on refresh, and there is no way to add a row without editing code. The tool did what you asked. You just asked for a shape, not behavior.
Models fill every unspecified gap with the most common answer in their training. “Sales dashboard” pulls in revenue totals, a line chart, and a filter bar because those appear together constantly in tutorials. Your business might need margin per route and nothing else. The model cannot know that unless you say it.
My rule: every unspecified detail is a vote for the generic default. You want to leave as few votes as possible.
The SCAR framework: four inputs that change the output
I named this after the thing it prevents, which is a scar of bad builds your team stops trusting. Four blocks, in this order.
- Screen: who opens it and what decision they make while looking at it.
- Columns: the exact fields, with data types, in the order you want them.
- Actions: what a user can click, edit, submit, or export.
- Rules: what must never happen, plus what counts as done.
Screen is the one most people skip. “Warehouse manager checking which pallets missed a scan before the truck leaves” gives the model a job to serve. “Inventory dashboard” gives it a template. Those produce very different apps.
Columns forces you to name real fields: pallet ID as text, scan time as a timestamp, dock number as a short integer, status as one of four fixed values. Vague fields become vague inputs, and vague inputs become a form with a free text box where a dropdown should be.
A side by side that shows the difference
Weak version, written in about fifteen seconds: “Build me a tool to track IT tickets for my team.”
The model returns a table with title, description, status, and assignee. It looks reasonable. Then your techs try to use it and discover there is no priority, no device tag, no way to see who has three open tickets and who has eleven. You rebuild. Twice.
Strong version: “An internal page my two support techs open each morning to see every open ticket sorted oldest first. Columns: ticket number as text, employee name as text, device type as one of laptop or desktop or phone, priority as one of low or medium or urgent, opened date as a timestamp, assigned tech as one of two names, status as open or waiting or closed. Only open items show by default. A dropdown at the top filters by tech. Each row has a close button that sets status to closed. Nothing is deletable.”
Same tool. Same amount of thinking, maybe four extra minutes of typing. The second version comes back usable because nothing important was left for the model to invent.
The data question you have to answer before you prompt
Ask yourself where the numbers live. If they sit in a spreadsheet the team already trusts, say so and name the columns. If they live in a real database, name the system and the tables. Your prompt should describe the connection plainly, because a build pointed at the wrong source produces confident wrong numbers, which is worse than an empty screen.
This is also where governance guidance matters. The National Institute of Standards and Technology publishes an AI risk management framework that treats data provenance and human oversight as core controls, not afterthoughts. Translated to your prompt: state what the app should show when data is missing or stale, and state who checks the output before anyone acts on it. One sentence each. It saves you an argument later.
How to test a build without wasting a week
Do not poke around and hope. Run the same three moves on every build:
- Feed it one deliberately messy record, like a blank priority field or a name with an apostrophe, and see what it does.
- Have a real user complete the actual task on a phone, not a laptop, once. Slow thumbs find layout problems fast.
- Check the empty state. Fresh apps with no data are where most builds quietly break.
I would rather ship a build with three columns that behaves correctly than ten columns that half work. Fewer fields, sharper rules, faster trust. Your team will forgive a missing filter. They will not forgive numbers they cannot believe.
Where prompts still run out of road
Some requirements belong in the tool’s configuration, not the prompt box. Access permissions for a contractor who should see one site and not the rest. A nightly job that pulls fresh figures. A display in the lobby that has to survive a browser restart. Prompting a paragraph about permissions and hoping the model wires up real authentication is where careful people get burned.
Screen deployments deserve their own note, since physical displays have quirks prompts rarely anticipate: fixed resolutions, no keyboard, and a machine that reboots without warning. The General Services Administration maintains accessibility and procurement standards that reflect how public-facing displays get evaluated in practice. If your app runs on a kiosk, mention refresh behavior and failure states in the prompt itself.
And keep the output portable. If your team can inspect the markup and styles, you can maintain the thing after the novelty wears off. The World Wide Web Consortium publishes the web standards that keep generated front ends from breaking in a browser update six months from now. Standard output is boring output, and boring is what you want in a tool people depend on.
Start with one screen you can describe out loud
Pick the smallest tool your team complains about this week. A shift handoff sheet. A parts reorder list. Something you could explain to a new hire in ninety seconds. Write it as who opens it, which columns, what they can click, what must never happen. Paste that in, then run the three tests above.
You will know within an hour whether the prompt was thin or the build was. Usually it is the prompt, and that is good news, because you control it. What is the one screen your team keeps rebuilding in a spreadsheet that a single careful prompt could replace by Friday?
