Write an app brief a builder can act on

Prepare a real task before setup

Replace “build a client portal” with a concrete scenario: a client submits a project request, sees its status and receives a response from the assigned operator. Name each role without assuming every role needs a separate account type. Include what happens before and after the task so the builder does not invent a workflow that looks attractive but serves nobody.

Define the minimum record

List the fields needed to complete that task and give each a fictional example. Mark which are required, which can change and which should never be collected. Decide whether a record can be deleted or merely closed. These decisions shape the app more than colors do. Avoid uploading private customer spreadsheets just to make a prototype feel realistic.

Define test steps for success and failure

Write an acceptance statement that another person could follow: submit a complete request, reload and confirm that the same request remains visible. Add the missing-field case, an unauthorized-user case and a repeated-click case. A good brief tells the builder what must not happen as clearly as it describes the happy path. Keep expected messages plain enough for the intended user.

Mark everything outside the first version

Explicitly defer reporting dashboards, payment collection, advanced automation and additional roles unless they are essential to the first task. Ask the builder to preserve that boundary during revisions. Keep the brief beside a dated test record so a later change can be checked against the same requirements. This is a repeatable writing method, not a guarantee that any model will follow every instruction correctly.

• Copy this brief structure: user, trigger, required input, permitted action, saved result, failure message and explicit exclusions. Fill it with one fictional example before asking for a generated first version.