What to include
The audience — who uses it
The audience — who uses it
Internal team only? Client-facing? Both? When the audience is mixed, name what each side does. “Our team assigns goals; clients check them off” tells the app builder two views, two workflows.
The outcome — what the app makes possible
The outcome — what the app makes possible
What does the app let someone do that they can’t do today? Lead with this. “Track which clients have completed onboarding” is an outcome. “A table” is not.
The primary actions — what users actually do
The primary actions — what users actually do
Not every action, just the core ones. “Internal user creates a goal, assigns it to a client, sets a due date. Client marks goals complete. Team gets notified when goals are completed or overdue.”
The business-specific definitions
The business-specific definitions
If your prompt uses a term that has a definition specific to how you operate — “at risk,” “onboarded,” “active,” “blocked” — say what it means. The app builder will guess otherwise, and the guess might not match how your firm thinks about it.
External services, if any
External services, if any
If the app should integrate with Stripe, Slack, Calendly, or something else, say so. The app builder will ask for the credentials during the build.
What to skip
UI specifics — colors, fonts, layouts
UI specifics — colors, fonts, layouts
The app builder uses Assembly Studio’s design system. Describing visual choices in the prompt rarely helps and often boxes the build into a worse layout than the one the app builder would pick.
Tech choices
Tech choices
Frameworks, databases, hosting, APIs. The app builder handles these. Mentioning them adds noise.
Schemas and data models
Schemas and data models
Don’t try to spec out the table structure. Describe what the app does and the app builder infers the data model from there.
Implementation steps
Implementation steps
The prompt is a description of the app, not a build plan. Leave the sequencing to the app builder.