How to write an app build prompt for an AI coding tool

Give the coding tool a product brief

A build prompt should explain the job before asking for code. An AI coding tool cannot infer which vague feature matters most to you, which information is private, or which existing files it must preserve. Make those decisions explicit enough that you can recognize a correct result.

The same brief can be adapted for tools such as Claude Code, Cursor, or Lovable. Their interfaces and capabilities differ, so treat the text as a specification rather than a promise that one prompt will produce a production-ready app. Review the tool’s plan and inspect the result at each step.

Include the information that changes the build

Describe a specific user, the situation that brings them to the app, and the outcome they need. Then give the smallest complete workflow. A list of nouns such as ‘dashboard, AI, analytics’ leaves the tool to invent the important behavior.

State your technical constraints only when they are real. In an existing repository, ask the tool to inspect the code and follow its conventions. In a new project, explain hosting or device requirements rather than choosing a large stack by default. Mark undecided details as questions instead of letting assumptions look like requirements.

• User and problem: who is doing what, and why the current method fails.
• Workflow: the actions and results needed for the first useful version.
• Data and access: what is stored and who may read, edit, or delete it.
• Boundaries: excluded features, permitted services, and cost limits.
• Quality checks: success, empty, invalid, and failure cases you will test.

A reusable build-prompt template

Fill in the brackets with concrete details. Leave out credentials, personal records, and private customer data; use fictional examples to explain a format. Ask the tool to identify blocking questions before implementing a guess that would be costly to undo.

Build a first version of [app].

User: [specific audience].
Problem: [current workflow and observable pain].
Success: [one result the user can achieve].

Core flow:
1. [Input or starting action]
2. [Main operation]
3. [Result, save, or export]

Data and access: [fields, persistence, permissions].
Constraints: [existing stack, devices, allowed integrations].
Do not include yet: [excluded features].
Failure states: [invalid input, network failure, unavailable service].

Acceptance checks:
- [Concrete happy-path check]
- [Persistence or permission check]
- [Concrete failure-path check]

First inspect the project, list assumptions and blocking questions, and propose a small implementation plan. Build and verify one complete flow before adding optional features. Explain what was tested and what still needs manual verification.

Replace vague requests with observable behavior

Instead of ‘build an AI feedback manager’, try: ‘A freelance designer pastes client feedback as plain text. Split it into editable items with an owner and an open/done status. Show unresolved items and export them as text. Preserve edits after a reload. If a parsing service fails, keep the original text and let the user create items manually.’

That version specifies an input, an output, persistence, and a fallback. It still leaves an important question: whether feedback can be sent to an external service. Resolve that before connecting one. The prompt should expose that decision, not disguise it as a technical detail.

Use a generated prompt as a starting point

Each idea on Post your build ideas includes a generated build prompt you can copy. Read the original idea, copy the prompt, and edit it to match your audience and first-version scope. Do not assume the idea’s author has already validated demand or resolved every implementation question.

After the tool builds something, run the acceptance checks yourself. Try an empty input, a failed save, a reload, and the smallest supported screen. If the app has private records, test access with separate users. Only claim a behavior works when you have evidence from the running app.