Writing a prompt that builds an app

The single biggest lever you have over a text-to-app tool is the first message. A model cannot ask a room full of stakeholders what they meant. It fills every gap in your description with the most statistically ordinary answer, so a vague prompt reliably produces a generic app.

A template that works

Copy this and fill in the brackets. It is deliberately short, and it covers the five things a model cannot guess.

Build a [type of app] for [who uses it].

Goal: [the one thing a user comes here to do].

Users and roles:
- [role]: can [actions]
- [role]: can [actions]

Data to store:
- [thing]: [fields]
- [thing]: [fields]

Core flow for the first version:
1. [step]
2. [step]
3. [step]

Not in this version: [features to leave out for now].

Look and feel: [two or three adjectives, or a site to take cues from].

The same prompt, filled in

Build a booking web app for a two-chair barbershop.

Goal: a customer books a haircut in under a minute without calling.

Users and roles:
- Customer: can see open slots, book one, cancel their own booking
- Barber: can see the day's schedule, block out time off

Data to store:
- Barber: name, working hours
- Service: name, duration in minutes, price
- Booking: customer name, phone, service, barber, start time, status

Core flow for the first version:
1. Customer picks a service, then a barber, then an open slot
2. Customer enters name and phone number and confirms
3. The slot disappears from availability and shows on the barber's schedule

Not in this version: online payment, text reminders, customer accounts.

Look and feel: clean, warm, mobile-first.

Compare that with “make a barbershop booking app”. Both will produce something. Only the first will produce your something.

Seven rules

1. Name the user and the goal first. “For a two-chair barbershop” changes dozens of small decisions.
2. Describe the data. Listing what the app stores is the most effective paragraph you can write. It fixes the database design, and the screens follow from it.
3. Say what is out of scope. Models over-build. An explicit “not in this version” list keeps the first result small enough to check.
4. Describe behaviour, not implementation. Write “a slot can only be booked once”, not “add a unique index”. Let the tool choose how, unless you have a reason.
5. One change per message after that. “Add text reminders” is a good follow-up. A list of six changes is six chances to break something, with no way to tell which one did.
6. Paste errors exactly. When something fails, copy the full error text. Do not paraphrase it.
7. Ask for tests. “Add tests for the booking flow and run them” gives the model a way to catch its own regressions. See How text-to-app AI works for why this matters as the app grows.

Mistakes that waste the most credits

• Restarting instead of refining. Regenerating from scratch throws away everything that was right. Fix the specific thing that is wrong.
• Arguing in circles. If three attempts have not fixed a bug, stop repeating the request. Ask the model to explain what it thinks is happening, or revert to the last working version.
• Polishing early. Colours and spacing are cheap to change at the end, and expensive to keep re-fixing while the structure is still moving.
• Skipping the plan. If the tool offers a plan before it builds, reading it is the cheapest review you will ever do.

If you are using a coding agent

The same rules apply, with two differences. The repository already answers many questions, such as the framework and the conventions, so prompts can be shorter and more task-shaped: “Add text reminders 24 hours before a booking, using the existing notification module. Add tests.” And because the work arrives as a diff, you can be precise in review: point at the line, say what is wrong.

AI app builders vs. coding agents explains when that switch is worth making.

Frequently asked questions

How long should a text-to-app prompt be?

Long enough to answer who uses the app, what they do in it, and what data it stores. For a first version that is usually 150 to 400 words. Shorter prompts leave the model to guess, and much longer ones bury the important parts.

Should I describe the whole app in one prompt?

Describe the whole app's purpose and data in the first prompt, but ask for only the core feature to be built. Add the remaining features one message at a time so each change is small enough to check.

Do I need to name a framework or database?

Only if you have a reason to. Hosted builders work best on their default stack, and naming a different one often makes results worse. With a coding agent in your own repository, the existing code already tells it what to use.