Skip to main content
The prompt is the most important thing you write in the app builder. The plan, the build, the eventual app — all of it traces back to how you described what you wanted. A good prompt isn’t long. It’s specific about the right things and silent on the rest.

What to include

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.
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.
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.”
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.
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

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.
Frameworks, databases, hosting, APIs. The app builder handles these. Mentioning them adds noise.
Don’t try to spec out the table structure. Describe what the app does and the app builder infers the data model from there.
The prompt is a description of the app, not a build plan. Leave the sequencing to the app builder.

Worked examples

Example 1: A client check-in app

Example 2: An internal deal pipeline

Example 3: A client request portal

Common mistakes

Trying to build several apps at once. “An app that tracks deals AND handles invoicing AND sends weekly digests” is three apps. The app builder will build one mediocre app instead of three good ones. Build them separately.
Over-specifying the UI. “A blue header with the logo on the left, four cards in a row, and a dropdown menu in the corner” is a design spec, not an app description. Describe what the app does; let the app builder handle the layout.
Under-specifying the trigger words. “Notify the team when something important happens” leaves the app builder guessing. Define what counts as important.
Skipping the audience. Studio will ask, but you’ll get a better plan if you say up front whether the app is internal-only, client-facing, or both.
When in doubt, write your prompt as if you were briefing a new team member who’s smart but doesn’t know your business. That’s roughly what the app builder is — capable, but it needs context that’s obvious to you.