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.

​
Starting from a suggestion

If you’re not sure how to phrase what you want, the prompt box gives you a starting point. Click Ideas below the box and pick one of the suggestions:
  • Onboarding wizard
  • Document collection
  • Person project tracker
  • Time tracker
  • Content approval flow
  • Service request intake
Picking one fills the box with a prompt you can edit before you build — change the wording to match your firm, add specifics, and cut anything that doesn’t apply. Everything below applies just as much to an edited suggestion as to a prompt you write from scratch, and the product agent runs its interview either way.
Several suggestions share a name with an app template, and the two do different things. A suggestion builds you a new app from your description; a template installs a working app you then modify. See App templates for how to choose.

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