Writing Prompts
A "prompt" is just the sentence you type into Appsanic to tell the agent what you want.
How you write that sentence is the single biggest lever on what Appsanic produces. Same tool, same AI, two different prompts: one builds a great feature, the other loops forever eating credits. This page is the field guide. If you read one docs page about working with the agent, make it this one.
The core idea: describe what the user sees, not how to build it
A common instinct is to write like you're giving instructions to a junior developer:
"Add a useState hook for loading and display a Spinner component while the data fetches."
If those words mean nothing to you. Perfect. That's exactly why you don't want to write prompts that way.
A better prompt describes what the user will actually experience:
"When the user opens this screen, show a loading state that feels gentle and doesn't flash if the data is fast."
Two things happened. You gave the agent room to make good decisions about timing, animation, and polish. And you didn't box yourself into one technical way of doing it.
Rule of thumb: describe what the user notices, not how the code should look.
- If you've never coded: good news. You don't need to know what
useStateor aSpinneris. You just need to describe what happens from the user's point of view. - If you write code: this frees the agent to pick the right pattern for your stack. Micro-managing at the hook level usually fights the agent instead of guiding it.
Ten prompt patterns that work
1. Describe the full user flow
Don't say:
"Add a delete account button."
Say:
"When a user wants to delete their account: from settings, they tap 'Delete account' in the danger zone; see a modal explaining deletion is permanent, can't be reversed, and takes 30 days to purge from backups; confirm by typing their email; and after deletion they're signed out and returned to the login screen with a brief goodbye."
The second prompt gets you a properly guarded deletion flow, not a red button that nukes the database the first time somebody double-taps.
2. Name the edge cases you care about
Don't say:
"Let users add friends."
Say:
"Let users add friends. Handle: the friend not being on the platform yet (send them an invite link), the friend having blocked them or been blocked, a duplicate request being sent, the sender canceling before it's accepted, and the recipient eventually accepting."
Edge cases you name upfront get handled upfront. Edge cases you don't name get discovered in production by confused users.
3. Give concrete references
Don't say:
"Make the profile screen look nice."
Say:
"Make the profile screen look like Instagram's profile: large avatar centered at the top, a row of stats below (followers, following, posts), a bio section, then a tab switcher between grid and list. Use our accent color (#7c3aed), not Instagram's pink-purple gradient."
"Like Instagram" is a thousand times more specific than "nice." Pointing at an app you and the agent both know is almost always the fastest way to describe a look.
4. Distinguish "add" from "redesign"
Don't say:
"Fix the settings screen."
Say:
"The settings screen's structure is fine. Keep the sections and spacing. Two changes: move the danger-zone items to the bottom in their own section with a subtle red accent, and replace the 'Help' link with 'Send feedback' that opens mailto:support@myapp.com."
Without a clear boundary, the agent may read "fix" as license to redesign everything. Save yourself the rework.
5. Use constraints deliberately
Don't say:
"Build an onboarding flow."
Say:
"Build an onboarding flow with these constraints: three screens max, phone-number sign-in only (no email or passwords), first screen explains the app in one sentence, second asks for notifications and camera permissions, third is the home screen with a welcome message. No tutorial overlays."
Unconstrained prompts produce the agent's median idea, which is almost always more complicated than what you actually wanted.
6. Batch related changes
Three separate prompts:
- "Change the primary color to a deep violet."
- "Buttons should have 16 px padding."
- "Cards should have 12 px border radius."
One prompt:
"Three small design updates, site-wide: primary color is now a deep violet (#5b21b6), buttons use 16 px padding (up from 12), cards use 12 px border radius (up from 8). Apply everywhere these patterns are used."
One prompt keeps the agent in a single mental context. Three prompts can produce three half-applied changes that contradict each other.
7. Ask for a plan before a commitment
If the feature is non-trivial, ask for the plan explicitly:
"Let's add comments to posts. Before you start, give me a brief plan: the data you'll store, the screens involved, whether you'll use realtime, and what edge cases you're considering. I'll approve before you write code."
On Pro, the agent plans by default. On Fast, you can ask it to plan first when the feature is big. See The Planning Phase for more.
8. Be explicit about ambiguity
The agent handles "I don't know what I want" better than "I know exactly what I want" when you actually don't:
"Make the feed infinite. I'm not sure whether to paginate by cursor or offset, and I'm not sure whether to refresh when the user pulls down. Propose both options with tradeoffs, then pick the one you'd build and explain why."
Owning up to ambiguity gets you better options than faking certainty.
9. Specify the feeling, not just the function
Don't say:
"Add a streak counter."
Say:
"Add a streak counter. It should feel delightful when the streak increases (small bounce, gentle haptic), a little heart-breaking when it breaks (soft crack animation, not dramatic, no shame). The streak should feel like a pet, not a KPI."
The second prompt produces an app moment users remember. The first produces a number on a screen.
10. Close the loop with success criteria
"Fix the login bug where a valid email and password returns a 'network error' even when online. Expected: successful login goes to home, failed login shows a specific error matched to the failure type. When you think it's fixed, walk me through what the bug was and how I can verify."
Success criteria turn "fix it" into a verifiable task.
Prompts that backfire
- Pasting a 2,000-word spec. A huge wall of text overwhelms the agent with noise. Five bullets of intent beat five paragraphs of detail.
- Asking for "best practices." Every agent thinks its output is best practice. The phrase is a no-op.
- Passive-aggressiveness. "I've told you a hundred times..." The agent doesn't care; restate the requirement and move on.
- Apologising. "Sorry to bother you, could you maybe..." Clarity helps; politeness doesn't.
- Mixing unrelated asks in one prompt. Three unrelated changes = three prompts. Otherwise the agent might apply one well and the other two half-heartedly.
The 30-second prompt audit
Before you hit send on any prompt that isn't a one-line tweak, run through this:
- Did I describe the user's outcome, not just the mechanism?
- Did I name at least one edge case?
- Did I include a concrete reference if aesthetics matter?
- Did I say what should stay unchanged?
- Did I invite the agent to surface misalignment before it commits?
Hitting three out of five turns a mediocre prompt into a strong one.
When to start a fresh conversation
When follow-ups stop fixing a tangled thread, the best prompt is often a new conversation: summarise where you are, restate the goal, and let the agent start with clean context. Conversations covers the signals and how the panel works.
Next
You now know how to write for the agent. Read Attaching Files & Images for an underused way to make prompts vastly more precise, or The Planning Phase to see how the agent reads you back.