How to Write a Prompt That Builds the Right App the First Time

Everyone who uses an AI app builder for the first time discovers the same thing: the tool is not the bottleneck, the description is. Two people can ask for "a CRM for my consultancy" and get results a week apart in quality, and the difference is entirely in what they said. This guide is about closing that gap deliberately rather than by trial and error.

The mental shift is small but it changes everything. You are not writing a command for a computer to execute literally. You are writing a brief for a capable contractor who has never met you, does not know your business, and will make reasonable assumptions about everything you leave out. Your job is to make the reasonable assumptions match the ones you actually want.

The five things every brief needs

Almost every underspecified request is missing one of five things. Run your description against this list before you send it and most of the correction rounds disappear.

One: who uses it

A visitor who never signs in, a customer with an account, and an administrator who manages content are three different applications wearing the same name. The number of distinct roles is the first structural decision in any app, because it determines whether sign-in exists at all and what each person is allowed to see.

Say it plainly: "anyone can browse, only I can edit" is a complete answer. So is "customers sign in with email, there is no admin, I will edit content by hand." What is not a complete answer is silence, because silence gets interpreted.

Two: what they do

The verbs in your description are the features. Book, cancel, pay, upload, filter, search, export, approve, invite — each one implies a screen, usually a button, and often a table. Listing the verbs is the fastest way to produce a feature list without knowing what a feature list is.

A useful exercise: describe one complete journey through the app in sentences, from arriving to being done. "A customer lands on the home page, picks a service, picks a time, enters their details, pays a deposit, and gets a confirmation email." That single sentence contains six features and two integrations.

Three: what gets stored

If you want to look at something later, it has to be saved somewhere. This is the part non-technical builders most often leave implicit, and it is the part that most changes the shape of the app. Naming the things you want to keep — bookings, orders, submissions, uploads, notes — is effectively designing the data model, and you can do it in plain nouns.

For each noun, it helps to say what you want to know about it. A booking has a time, a service, and a customer. An order has items, a total, and a status. You do not need database vocabulary to say that.

Four: the screens

Even a rough list gives the plan a skeleton: home, services, booking, confirmation, admin. If you cannot list the screens, that is a useful signal in itself — it usually means the idea is still a feeling rather than a product, and the fastest way to fix that is to sketch the screens on paper before you type anything.

Five: whether money changes hands

Payment is the single largest fork in the design of an app. It brings a checkout flow, states for success and failure, a record of what was paid, and usually an account to attach the payment to. Say yes or no early rather than adding it in week two, because retrofitting money into an app that was designed without it is one of the more expensive changes you can ask for.

You do not need technical vocabulary to write a technical brief. You need nouns for what you keep, verbs for what people do, and honesty about who is allowed to do what.

A worked example, three drafts deep

Take a real-shaped idea and watch it improve. The idea: a tool for a small tutoring business.

Build me a website for my tutoring business.

This produces something. It will be a tidy marketing page, because in the absence of any other information a marketing page is the most reasonable interpretation. If what you wanted was a scheduling system, you have just spent a build learning that.

A website for a tutoring business where parents can book sessions.
Show the subjects I teach and let parents request a time.
I want to see the requests somewhere.

Better. There are now two roles implied, a stored thing (requests), and a screen for reviewing them. But "request a time" is ambiguous — is it a form that emails you, or a calendar with real availability? Those are very different builds.

A booking site for a one-person tutoring business.

Public side (no sign-in):
  - A page listing four subjects, each with a level, a rate and a blurb.
  - A booking form: subject, preferred day, preferred time, parent name,
    email, phone, and a free-text note.
  - Submitting saves the request and emails the parent a confirmation
    that the request was received (not that it was accepted).

Private side (only me, behind sign-in):
  - A list of requests, newest first, with a status of new / accepted /
    declined that I can change.
  - Changing status to accepted emails the parent.

No payments for now. I may add deposits later.

Draft three is not longer for the sake of it. Every added line removes a decision the agent would otherwise have had to make on your behalf. It also resolves the ambiguity in draft two explicitly: this is a request form with a manual approval step, not a live calendar. And it flags the future direction — deposits later — which is exactly the kind of context that leads to a design that can accommodate it.

When to be vague on purpose

Specificity is not free. There are places where over-specifying makes the result worse, and it is worth knowing where they are.

• Visual style. Describing a look in adjectives rarely beats attaching a reference image or picking a template and editing from there. "Clean and modern" means nothing; a screenshot means something.
• Implementation choices. Naming a library or a pattern you half-remember constrains the build for no benefit. Describe the behaviour you want and let the choice follow.
• Copy. Ask for placeholder copy and rewrite it later. Writing final marketing copy inside a build prompt slows the build down and you will rewrite it anyway.
• Edge cases in the first pass. What happens when two people book the same slot is a real question, but it is a second-round question. Get the main path working first.

The scoping conversation is where the brief finishes

A new project opens in chat before it opens in a build. The agent asks about the parts of your idea it cannot guess — who signs in, what gets stored, whether money changes hands — and fills in a blueprint as you answer. This is the second half of your brief, and it is the cheapest place in the entire process to change your mind.

Two habits make this stage productive. First, answer the question that was asked rather than the one you expected — if the agent asks who signs in and you answer with a feature idea, the gap stays open. Second, volunteer the thing you have been assuming. Most misbuilt apps trace back to a fact the builder considered too obvious to mention.

When the blueprint control changes from Blueprint to Review blueprint, the agent believes it has enough to build from. Open it. It shows what is about to be built and which services it will use, each marked as managed for you or connected under your own account. Read that list the way you would read a quote from a contractor: not for the prose, but for the line item that is missing or wrong.

Prompt patterns that reliably waste a build

1. The compound request. Five unrelated changes in one message produce one large diff that is hard to verify and hard to attribute when something breaks. Ask for one thing, look at it, then ask for the next.
2. The pronoun with no referent. "Make it bigger" after three paragraphs of discussion is a coin flip. Name the thing, or better, select it visually.
3. The location description. "The second button in the third card" is slower to write and less precise than clicking the button in the Studio live mode and describing the change against that focus.
4. The unstated role change. Asking for an admin page halfway through a project that was scoped without sign-in is a structural change wearing the costume of a small one. Say so explicitly.
5. The style adjective. "Make it look more premium" gives the agent nothing to aim at. Attach a reference image instead.
6. The silent assumption. Every fact you think is too obvious to state is a fact the agent will guess at.

How to phrase a change request

Once an app exists, briefing shifts from describing a thing to describing a delta. A good change request has three parts, and you can write it in one sentence: what should be different, where, and what should stay the same.

weak:   "the booking form needs work"

better: "On the booking form, make the phone field optional and add a
         dropdown for preferred contact method (email or phone).
         Leave the rest of the form as it is."

The final clause matters more than it looks. Explicitly fencing off what should not change is the cheapest way to keep a diff small, and small diffs are easier to verify, easier to review, and easier to undo.

What to do when the result is wrong

Resist the urge to re-describe the entire app. The productive move is almost always to name the specific gap and let everything else stand. If the agent built a public listing where you wanted a private one, say that — do not start over.

It also helps to check the feature inventory rather than trusting your impression of the preview. Repository → Features lists what has been built and whether the most recent build confirmed it still works. If something you asked for is not on that list, it was not built, and that is a much more actionable finding than "it does not feel finished."

And when a build fails outright, the failure itself is usually the brief talking back to you. Reply in chat with the missing context — a value the agent did not have, a convention it got wrong, a test that was already failing before it started. The run is recorded either way, so nothing is lost by reading it before you retry.

A checklist you can actually use

1. Name the roles. Who is anonymous, who signs in, who administers.
2. List the verbs. Every action anyone takes.
3. List the nouns you keep. Everything you want to look at later.
4. List the screens. Even roughly.
5. Answer the money question. Yes or no, now.
6. Attach a reference for anything visual instead of describing it.
7. Send it, then answer the scoping questions honestly rather than briefly.
8. Read the blueprint for the missing line item, not for the prose.

None of this requires learning to code. It requires being explicit about a business you already understand, which is a skill you can practise on the very first project and keep forever.