Guides / Prompting and shipping

How to Write Prompts for AI App Builders (With Before-and-After Examples)

Prompt patterns that get AI app builders to build what you meant: what to include, what to leave out, before-and-after examples, and how to iterate.

Mythex Team · 2026-09-29 · 8 min read

A good prompt for an AI app builder describes the product, not the code: who uses it, what they do step by step, what data it keeps, and who is allowed to see what. After the first version exists, ask for one specific change per message, say what must stay the same, and describe problems as "I did X, expected Y, got Z". Those three habits fix most disappointing results.

The rest of this guide shows the patterns in detail, with before-and-after examples you can adapt.

Why prompting an app builder is different from chatting with an AI

When you ask a chat assistant a question, a vague prompt gets a vague answer and you move on. When you prompt an AI app builder, the answer is a running program. Every gap in your description gets filled with a guess, and those guesses become code, database tables and screens you then have to live with or undo.

So the goal of a prompt is not to sound clever. It is to leave fewer important decisions to chance. You don't need technical vocabulary for that. You need to be specific about the things only you know: your users, your workflow and your rules.

What to include in a first prompt

Before you write anything, answer these questions. Each one closes a gap the AI would otherwise guess at.

That last row is underrated. Saying what you don't want stops the AI from adding a blog, a pricing page and a newsletter signup you never asked for.

Before and after: the first prompt

Before:

Make me an app for my gym.

The builder has to guess everything: members or staff? Classes or personal training? Payments? You'll get something that looks like a gym website and does nothing you need.

After:

Build a class booking app for a small yoga studio. Members see this week's classes (name, teacher, time, spots left), book a spot, and cancel up to two hours before. Members sign up with email and password. The studio owner logs in to add classes, see who is booked, and mark attendance. Store classes, members and bookings in a database. Calm, light design that works well on phones. No payments yet.

The second version is still short. It just answers the questions from the table above.

Describe behaviour, not implementation

You'll often get better results by describing what should happen rather than how to build it.

Before:

Add a useEffect that fetches bookings and a modal component for editing.

After:

When the owner clicks a booking, open a panel where they can change the time or cancel it. Changes should show up straight away in the list.

The first prompt locks the AI into a specific technique that may not fit how the app is built. The second tells it the outcome and lets it choose the right approach for the code it already wrote. If you are a developer and you do have a strong preference, say it, but pair it with the outcome.

Be concrete about the rules

Business rules are where AI-built apps most often go wrong, because they are obvious to you and invisible to the AI. Spell them out.

• Limits: "A member can hold at most three future bookings."
• Timing: "Cancellations close two hours before the class starts."
• Edge cases: "If a class is full, show a waitlist button instead of Book."
• Permissions: "Teachers can see their own classes' attendance but not other teachers'."

Each of these is one sentence. Leaving any of them out means the app will either not enforce the rule or invent its own version of it.

After the first version: one change per message

Once something is running in the preview, switch from describing the whole product to asking for small, checkable changes.

Before:

The design is off, the booking doesn't work properly and I want a calendar view and emails.

After (as four separate messages):

1. When I book the last spot in a class, the class still shows "1 spot left". It should show "Full" and hide the Book button.
2. Add a week view calendar on the schedule page, one column per day. Keep the current list view as an option.
3. Make the class cards more compact on phones: smaller padding, teacher name on the same line as the time.
4. Send the member a confirmation email when they book.

Why this works:

• Each change is small enough for the AI to get right in one pass.
• You can test each one before moving on.
• If one goes wrong, you can roll back just that step without losing the others.

Say what to keep

When you ask for a change to something that already works, tell the AI what must not change. This is the single easiest way to stop regressions (things that used to work breaking after an edit).

Redesign the home page hero with a bigger headline and a photo on the right. Keep the navigation, the colours and everything below the hero exactly as they are.

The same applies to data: "Add a phone number field to members. Don't remove or rename any existing fields."

Use screenshots and exact text

Words like "the thing at the top" are ambiguous. Most AI app builders accept images, and a screenshot with a short note is faster than a paragraph of description.

• Attach a screenshot and say "the button circled in red overlaps the menu on phones".
• Paste the exact text of any error message rather than paraphrasing it.
• Quote on-screen labels exactly: "the Save changes button on the Settings page".

For bugs specifically, use this shape:

On the bookings page, I clicked Cancel on a booking for tomorrow. I expected it to disappear from my list. Instead nothing happened and the booking is still there after refreshing. Fix it and check that cancelling works.

Our guide on how to debug an AI-built app goes deeper into this.

Plan first for big changes

For anything that touches many parts of the app — adding user accounts to an app that had none, adding payments, changing how data is structured — ask for a plan before any code changes.

Before changing anything, explain how you'd add team accounts: what new tables, which pages change, and what happens to existing users. Don't edit code yet.

Read the plan. If it misunderstands something, correcting a paragraph is much cheaper than correcting a finished feature. Many builders have a dedicated mode for this; on Mythex it is Plan mode, alongside Build and Ask.

What to avoid

On API keys: if you need a payment or email service, put its keys in the project's secrets rather than the prompt. See what environment variables and secrets are if that's new.

Reusable prompt templates

Adapt these by replacing the bracketed parts.

New app:

Build a [type of app] for [who]. They [main flow, step by step]. [Second type of user] logs in to [what they do]. Store [data] in a database. [Look and feel]. Leave out [things for later].

New feature:

Add [feature] to the [page]. When [user] does [action], [what should happen]. Only [who] can [do it]. Keep [existing things] as they are.

Design change:

On the [page], change [specific element] to [specific change]. Keep [what to keep]. Check it looks right on a phone-width screen.

Bug:

On [page], I [steps]. I expected [expected]. Instead [actual, plus exact error text]. Fix it and verify the flow works.

Question without changes:

Don't change any code. Explain how [part of the app] works and where [data] is stored.

Writing a longer spec

For bigger projects, it can help to write a one-page brief first and paste it in as your opening prompt: the users, the core flows, the data, the rules and what's out of scope. You can even have an AI help you draft it — our guide to writing a product requirements doc with AI covers how. Just keep the first build request to the core flow, and add the rest step by step.

Prompting in Mythex

Everything above works in Mythex. A few specifics that help:

• Build, Plan and Ask modes. Use Plan for large or risky changes and Ask when you want an explanation without edits.
• Checkpoints. After each successful change Mythex saves a checkpoint, and Revert to this point on a reply rolls the project back. You can also edit an earlier message and resend it to try a different prompt from that point.
• Secrets card. When the agent needs an API key, it asks through a card in the chat so the value is stored as a project secret rather than written into your message.
• Images. Attach screenshots or mockups and the agent will look at them.

The docs have a short page on effective prompts and one on iterating without rebuilding. If you're starting from scratch, how to build an app with AI walks through a full project, and how to design a good-looking app with AI covers prompts for visual polish.