Writing prompts

How to write initial and follow-up prompts that produce better output.

The quality of what Build generates is directly tied to the quality of the prompt. This page covers what to include in an initial prompt and how to phrase follow-ups for precise iterative changes.

---

Initial prompts

An initial prompt should describe the app in enough detail that Build can make confident decisions about architecture. You don't need to specify every detail, but the more you cover, the less Build has to guess.

Useful things to include:

• The app's core purpose in one or two sentences

• The main user roles and what each one does

• The key pages or views

• Any specific technical requirements (database, auth method, third-party integrations)

• Visual preferences, if they matter dark mode, a reference product, a color palette

Example vague prompt

Make a web app for managing tasks.

This works, but Build will make many assumptions. The output may not match what you had in mind.

Example specific prompt

Build a task manager for small teams. Users can sign up and belong
to a workspace. Inside a workspace, users can create projects and
add tasks with a title, description, due date, assignee, and priority
(low / medium / high). Tasks can be viewed in a list or Kanban board.
Include email notifications when a task is assigned. Dark mode by default.

This gives Build enough to make the right decisions on architecture, data model, and UI without over-constraining it.

---

Follow-up prompts

Follow-ups are instructions to modify the existing codebase. Be specific about what you want changed and, if relevant, where.

Instead of	Try
Fix the dashboard	The KPI cards on the dashboard are not aligned on mobile. Stack them vertically below 768px.
Add payments	Add Stripe Checkout for a single $29/month subscription plan. Redirect to /dashboard on success.
Make it look better	The sidebar feels cluttered. Remove the icon labels and increase the spacing between nav items.

---

Referencing real-world products

It's useful to reference an existing product as a visual or structural reference. Build understands these references and uses them to guide layout and interaction patterns without copying them.

The dashboard layout should feel similar to Linear clean, minimal,
keyboard-navigable, with a command palette.

The onboarding flow should work like Notion's one step at a time,
no forced sign-up before showing the product.