Build Your First Agent App

A first app should help one person make one decision or complete one job. 'Build a dashboard' describes a shape, not a purpose. 'Help an office manager turn a facilities request into an assigned owner and due date' describes a user, input, transformation, and outcome. Agent can design the interface more reliably when the work is concrete.

Choose a workflow you understand well enough to judge. It can serve sales, operations, finance, recruiting, customer support, education, or your household. Avoid starting with payments, medical data, destructive automation, or a large multi-role product. The first goal is to learn the build loop on a reversible problem.

A useful first prompt contains the user, pain, successful journey, essential records, visual tone, constraints, and acceptance checks. It does not prescribe every component. Tell Agent which facts are real, which may be mocked, and what it must not add. This prevents a small app from becoming a generic platform.

Use examples. If the user submits a request, include two representative requests and the output each should produce. Examples expose hidden policy: required fields, categories, deadlines, and status transitions. They also become fixtures for later testing.

Let Agent establish the application, then read its task list and checkpoint summaries. Intervene when the product meaning is wrong, a constraint is ignored, or the build introduces unapproved scope. Do not interrupt solely because a file name looks unfamiliar. Ask what responsibility the file has and how the app proves it works.

After each meaningful checkpoint, test the journey yourself in Preview. Enter realistic data, reload the page, try an invalid submission, and inspect whether the result remains understandable. One successful happy path is a starting signal, not the finish line.

Give revision prompts that point to evidence: 'On a 390-pixel-wide screen, the submit button is below a horizontally scrolling table. Replace the table with stacked cards on narrow screens and keep the desktop table.' This is more actionable than 'make mobile better.' Include what must remain unchanged.

Separate product corrections from visual polish. First fix whether the workflow produces the right state. Then improve hierarchy, language, spacing, and responsiveness. Bundling logic, data, design, and a new integration into every prompt creates large diffs that are difficult to test and roll back.

A checkpoint is a recoverable milestone and a record of what Agent changed. Read its summary and inspect the changed files. Ask Agent to explain the data flow in plain language: where input is validated, where state is stored, and where errors appear. This is how a nontechnical builder gradually becomes able to supervise technical work.

Before advancing, write a release note for yourself: what now works, what is intentionally fake or temporary, what remains untested, and which checkpoint is the safe return point. This avoids discovering weeks later that a polished demo depended on in-memory sample data.