Plan your app idea before you prompt

Why prompting without a plan costs you time

Type “build me an app for booking yoga classes” and the AI won’t stop to ask what you meant. It fills every gap with a guess: who logs in, what counts as a booking, what happens when a class is full. The result looks finished. That’s the trap.

The guesses catch up with you later. You ask for a change, the AI reworks something it invented on its own, and a part that worked breaks. You fix that, and something else breaks. Nobody ever decided how the app should behave, so every prompt stacks a new guess on the old ones. It doesn’t help that the same prompt can produce different code each time you send it, as this analysis of fix-and-break loops shows.

The people who make these tools say the same. Anthropic’s guide to Claude Code, its AI coding tool, warns that letting the AI jump straight to coding “can produce code that solves the wrong problem.” Cursor, another AI coding tool, says planning “forces clear thinking about what you’re building.”

Complete enough on paper before code · From the Faber knowledge base

What goes into a one-page plan

You don’t need a long document. You need one page that answers six questions in plain words. If you can’t answer one of them yet, that’s the most useful thing the page can tell you: it’s exactly the spot where the AI would have guessed.

• The goal in one sentence. What the app does and for whom, for example: “Members of my yoga studio book a spot in a class from their phone.”
• Who it’s for. One kind of user to start with. “Everyone” is not an answer.
• The three to five things V1 must do. V1 is the first version you’ll actually use. Keep only what the goal can’t work without; that’s your “must do” list.
• What V1 leaves out on purpose. Payments, an admin area for managing everything, an app people download from an app store: put them on a “later” list so they’re decided, not forgotten.
• The one core flow. The path a user takes from opening the app to getting what they came for, in four to six steps.
• Done when. Three to five things you can check yourself. That’s your “done when” list, for example: “A member books a class and sees it under My bookings.”

The “later” list matters as much as the “must do” list. AI tools make adding features feel free, so anything you haven’t ruled out tends to creep in. A written “not now” is a decision you can point to. Lovable, an AI tool that builds apps from descriptions, puts it plainly in its prompting guide: “Vague ideas produce vague outputs.”

The smallest coherent V1 · From the Faber knowledge base

Turn the page into your first prompt

With the page done, the first prompt almost writes itself. Don’t paste the whole plan and ask for the whole app. Give the goal and the “later” list as background and ask for one piece: the core flow, or the first part of it.

A good prompt has four parts: the goal, the scope (what to build and what not), what must keep working, and when it’s done. Copy the template below into your AI tool’s message box and replace everything in [square brackets] with what’s on your page.

Goal: [one sentence from your plan]
For: [who uses the app]

Build only this step: [the core flow, or one part of it]
Out of scope for now: [your “later” list]
Must keep working: [what already works, or “nothing yet; this is the first step”]

Done when:
- [check 1]
- [check 2]
- [check 3]

Before you write any code, ask me up to three questions about anything that is unclear. Then describe your plan in a few sentences and wait for my OK.

The last two sentences do the heavy lifting. They turn the AI from a guesser into a builder that has to check with you first.

Let the AI ask you questions first

Even a good page misses something. That’s normal. The cheapest moment to find the gap is before any code exists, so let the AI look for it.

Many tools have a planning mode built for exactly this. In Cursor’s Plan Mode and Lovable’s Plan mode, the AI asks clarifying questions and proposes a plan you can edit before any code is written. Claude Code has a planning mode too, where it only looks at your project and answers without changing anything. No such mode in your tool? The last two sentences of the template do the same job.

1. 1Send the prompt and read the questions. Answer them in one reply, short and concrete.
2. 2If a question uncovers a real gap, add the answer to your page as well, so it doesn’t get lost in the chat.
3. 3Read the plan the AI proposes and compare it with your “later” list. Anything from that list in the plan? Tell the AI to drop it.
4. 4Only then reply “OK, build it” and let it build.

One feature per prompt

Once the first step works, it’s tempting to ask for the next three at once. Don’t. One prompt, one feature, then check it against your “done when” list before you move on.

Small steps keep changes small enough to understand. When something breaks, you know which prompt caused it, and going back costs one step, not an afternoon. A big prompt does the opposite: lots of changes land at once, and a problem hides among the ones you never looked at.

Anthropic’s guide has a handy rule for when a plan is overkill: “If you could describe the diff in one sentence, skip the plan.” The diff is simply the list of changes the AI makes. Fixing a typo needs no plan. A new feature does.

1. 1Pick the next item from your “must do” list.
2. 2Write a prompt with the four parts: goal, scope, must keep working, done when.
3. 3Let the AI ask its questions, then let it build.
4. 4Check the result yourself against your “done when” list. Only then move on.
5. 5New idea along the way? Add it to your “later” list, not to the chat.

When the result drifts anyway

Sometimes the AI still builds something other than what you meant. The reflex is to correct it in the chat, again and again. Cursor recommends the opposite: undo the changes, make the plan more specific, and run it again. According to Cursor, that is often faster than fixing an AI that is already in the middle of the work.

This is where your page pays off twice. You don’t have to argue with a pile of code. You change one line on the page, like a sharper item on your “done when” list or one more item on your “later” list, and start the step again from the version before the failed attempt.