The Planning Phase

Most AI coding tools start typing within half a second of your prompt. It feels responsive. It also produces a lot of code that gets thrown away.

Appsanic does the opposite. When you prompt the agent, it pauses. Usually a few seconds on Fast, longer on Pro. And thinks. You see a plan before any code appears. That pause is deliberate, and it's where most of the quality comes from.

What happens during the pause

Nothing mystical. The agent walks a checklist:

1. What's already there. Which screens exist? What's in the navigation? Which reusable pieces are there? What style choices has the app already made?
2. The shape of the data. What new information does this feature need to remember? Lists of what? Can we add to something existing, or do we need a fresh place to store this?
3. The user flow. How does a user enter this feature? How do they leave? What does the screen look like when it's loading? Empty? Broken? These are the details that separate an app that feels real from one that feels like a demo.
4. The services. Does this feature need payments, emails, push notifications, real-time updates, maps, crash reporting? If yes, is the right service already connected? The agent won't guess at a missing one - it pauses and asks you to connect it.
5. What the prompt left open. The agent keeps a running list of choices it had to make on your behalf and surfaces them: "I assumed invites expire after seven days; let me know if you'd prefer a different window." An ambiguity cleared up at the plan stage saves twenty minutes once the code's being written.

What a plan actually looks like

Here's an abridged example from a real prompt: "Let's add comments to posts."

1. Data: a new comments list. Each comment remembers which post it's on, who wrote it, the text (max 500 characters), and when it was written.
2. Feed: show a small comment count under each post. Tapping opens the post detail.
3. Post detail screen: the post at the top, comments below in order, and a text input pinned at the bottom that lifts above the keyboard when you type.
4. Live updates: new comments appear for everyone viewing the post without a refresh.
5. Delete: users can delete their own comments. We "soft delete" so replies below still make sense.
6. Report: long-press a comment to report it. Adds a row to a separate reports list we'll create.
7. Notifications: when someone comments on your post, you get a push. You don't get notified about your own comments.
8. Edge cases: if the post is deleted, the comments page handles it gracefully. New comments appear immediately for the author and revert if something goes wrong.

That's a lot of decisions. You get to push back on any of them before a single line of code is written. If you don't want reporting, say so now. If notifications are out of scope for v1, say so now. Changing a bullet in a plan costs nothing. Undoing a deployed moderation system costs a day.

For engineers: behind the plain-English bullets, the agent is picking things like a comments(id, post_id, user_id, body, created_at, deleted_at) schema with an index on post_id, RLS policies, a Zustand store named comments-store.ts with fetchForPost / create / delete, and a Supabase Realtime subscription scoped to the open post. Click into the plan to see any of that. Most people don't need to.

The three ways you can respond to a plan

1. Approve it

Hit Approve. The agent starts writing. Best when the plan looks right and complete.

2. Adjust, then re-approve

Type your corrections in plain English:

"Skip reporting for v1. We'll add it later. Good that you're not notifying the author about their own comments. Use 'newest first' as the default sort, not oldest."

The agent revises the plan. You approve the revised version.

3. Ask for alternatives

When an architectural choice looks non-obvious, ask for options:

"Before you approve, give me two options for real-time comments: live updates versus just polling every ten seconds. Tradeoffs, then your recommendation."

The agent writes out both options and recommends one. You pick.

Why the pause is worth it

Planning costs tokens. Pro uses noticeably more of them than Fast. Fair question: is the pause worth the credits?

On the kind of multi-screen, multi-file feature Pro is built for, the time it spends planning usually pays for itself in fewer follow-up corrections. The first attempt lands closer to what you wanted, so you spend less of the budget on revisions afterwards.

The framing that matters isn't "tokens spent thinking". It's "tokens spent building a working feature." Every second the agent spends reasoning before writing is a second you don't spend reviewing, re-explaining, and asking for another try.

When to skip planning

The plan is most valuable when a feature touches multiple parts of the app. For simple changes. A color tweak, a copy fix, a one-line bug. It's overkill. Fast handles these quickly without an elaborate plan. That's what Fast is for.

See Fast vs Pro for when to pick which.

Beyond the planning phase, the agent will occasionally pause mid-build for a clarifying question when the next step depends on a choice only you can make - or stop with a connect card when it needs a service you haven't connected yet. Connect it from the card and the build resumes on its own. See In-Chat Connect Cards.

Next

Now you know how the agent plans. Read Fast vs Pro to understand which model to reach for, and why.