App Brief
The app brief is the first durable definition of what the app is meant to do. It is a concise, editable source of truth that captures the app name, summary, functions, user roles, data requirements, authentication and access expectations, and any reusable guidance that should carry into later build stages.
In Builder MCP and Buzzy AI workflows, the brief comes before flows, data model, theme, blueprint, sample data, and screens. Downstream stages should use the accepted brief as the product intent, not reinterpret the original prompt from scratch.
What the Brief Controls
Name and summary
Sets the product frame and keeps generated artifacts aligned to the same app concept.
Functions
Describes what users should be able to do and who each capability is for.
External functions
Captures server-side behavior, webhooks, external APIs, AI calls, and other Buzzy Function requirements before implementation begins.
User roles
Defines the people or groups the app needs to support, such as customer, staff, reviewer, admin, or public visitor.
Data requirements
Tells the data-model stage what records, relationships, and fields need to exist.
Authentication requirements
Records whether the app is public, signed-in, role-based, invite-only, or requires onboarding/profile capture.
Cookbook context
Stores reusable domain, workflow, and design guidance selected during brief construction so later stages can reuse the same assumptions.
Where it Fits in the Build Flow
For a new app, the staged flow is:
Create or generate the brief.
Review and accept the brief.
Generate flows from the accepted brief.
Generate the data model from the accepted brief and flows.
Generate theme and blueprint from the accepted product direction.
Ensure screens, wire navigation, generate sample data, and build screens.
If the brief is wrong, downstream artifacts will usually be wrong in more expensive ways. Fix the brief first when the product goal, users, data, security posture, or integration requirements change.
Good Brief Hygiene
Keep it high-level enough to guide the whole app, but specific enough to prevent vague downstream generation.
Capture user roles and access expectations early.
Put server-side or external integration requirements in external functions rather than hiding them in screen notes.
Include important domain constraints, approval steps, lifecycle states, and edge cases.
Review generated cookbooks or reusable guidance when present, because those assumptions can shape later stages.
Related Pages
Last updated