How to explain your app idea before AI starts building

Before you ask AI to build, tell it what someone should be able to do. A feature brief is simply a short note about that change. You don’t need a technical specification: describe the person, the problem, the smallest useful result, and anything you want to leave for later. That gives your AI a direction you can check.

Separate the request from the proposed solution

“Add a dashboard” names a solution. “I cannot tell whether my export finished” names a problem someone can recognize. Keep the supplied observation beside the proposed solution so that the assistant can suggest a smaller version without pretending customer demand has been established.

In this fictional example, an existing screen already lists exports. Showing state and recovery there might solve the stated problem. Email notifications could be useful later, but no evidence for them was supplied. Writing them into the first version would enlarge the task without answering a confirmed need.

Give the assistant a boundary

The unknown belongs in the brief. If cancelled and failed jobs have different retry rules, the team needs to resolve that distinction. If the only missing choice is whether the worksheet uses bullets or a table, a plain default is sufficient.

Write checks someone can observe

“Make exports intuitive” is difficult to verify. A stronger check says: given a known job that becomes ready, the owner sees Ready and can retrieve its file. Another says: a user without ownership cannot retrieve that file by copying the address.

You can use these checks with any stack. Implementation details still come from the current repository. The assistant should not invent an API endpoint, storage provider or refresh interval to make the brief look complete. If a requirement depends on one of those choices, state the decision rather than guessing its answer.

Copy a small feature brief

User and situation:
Observed problem and its source:
Desired outcome:
Smallest useful change:
Non-goals:
Confirmed constraints:

Acceptance checks:
- Starting state:
- Action:
- Observable result:

Failure and recovery behavior:
Unknowns that could change this version:
Next decision or check:
Keep proposed behavior separate from observed current behavior. Use the project's existing issue or specification format if one exists.

Read the brief before coding begins. Remove statements you cannot support. If a number, deadline or policy appeared without a source, ask where it came from. An assistant can make a guess look like a requirement, and that guess can survive several later handoffs.

Keep small changes small

A label fix may need only its intended wording and a quick check that it fits the screen. A change to private downloads needs more attention to ownership and recovery. Use the consequence of being wrong to decide how much detail is useful.

If your team already keeps requirements in an issue tracker, leave them there. The brief is a structure for decisions; it does not require adopting a new file naming scheme. Link the source of truth rather than copying conflicting versions between tools.

You can use the template above for free. Build Brief also includes a reusable workflow and a worked example. Once the brief exposes an actual design choice, move to Build Choices; when a diagram would help the conversation, try the free Sketch Diagram.