Writing better prompts

What you type is the biggest lever on what you get back. This page gives you one formula for the first prompt, a few rules for describing the look, and templates you can copy. Read it top to bottom once; after that, the checklist at the end is all you need.

Not built anything yet? Do the Quick Start first, then come back here.

#Step 1 — Write the first prompt with the five-part formula

Every good first prompt answers the same five questions. One or two sentences each is enough.

Put the five parts together and you have a complete prompt:

A one-page website for Maple Lane Bakery, for people checking the menu and hours on their phone.
Sections in order: hero with the bakery name and tagline, a menu with six items and prices,
opening hours, and a contact form that saves messages so I can read them later.
Warm and simple: cream background, one brown accent colour, large friendly headings.

Three things to keep in mind while you write it:

• Specific beats long. Four precise sentences work better than two vague paragraphs.
• Describe the result, not the technology. "Customers pick a barber, a service, and a time slot" is a better instruction than "use a React date picker." MeDo chooses how to build it.
• Use the real words. Placeholder text you leave in the prompt — "Coming soon", "Lorem ipsum", "$XX" — ends up on the finished page. Give MeDo the actual headline, prices, and address.

Already have a written brief? Attach it instead of pasting: click + → Upload in the prompt box. MeDo reads txt, doc, docx, and pdf, up to 5 files of 20 MB each. See Creating a site.

#Step 2 — Describe the look so it lands the first time

"Modern" and "clean" mean something different to everyone. Three rules fix that.

Rule 1: Name something real instead of using adjectives.

• Not "clean and minimal" → "like the Apple product page"
• Not "warm and welcoming" → "like a Muji store: off-white, wood tones, one small sans-serif logo"
• Not "elegant" → "like an old hotel matchbook: dark green background, small gold letters, thin lines"

Pick one reference. Mixing three styles gives you three half-finished ones.

Rule 2: Say what you do not want — for the two or three things you care about most.

• "Pure white background, not cream."
• "A rounded sans-serif font — no cursive, no italic."
• "One accent colour, red, used only on buttons."
• "Photos of real people, not stock photos of laptops."

Rule 3: Ask for one animation at most, in plain words. "When the page loads, the title fades in from the bottom." Asking for many animations makes the page feel busy, not polished.

#Step 3 — Check the plan before MeDo builds

After your first message MeDo does not build straight away. It writes a requirements document with three tabs — Requirements, Style, and Backend — and waits for you.

This is the cheapest moment to change your mind:

1. Read all three tabs. Check the pages, the fields in each form, and what the app stores.
2. Anything wrong? Click Edit and change the text directly, or reply in the chat ("drop the newsletter section; add a map to Contact").
3. Look at Out of scope at the bottom — it lists what MeDo has deliberately left out, so you can pull anything back in.
4. When the document says what you want, click Generate App.

Fixing a sentence here takes seconds and costs nothing. Fixing the same thing in a finished app takes another message and more credits.

#Step 4 — Ask for changes after the build

Once the app exists, the rules change slightly:

• Name the place. "On the Services page, right-align the price column" beats "fix the alignment."
• One change per message. A single clear request usually lands; a list of six often lands partially.
• Point at it. For anything visual, use Edit mode or the Screenshot tool to mark the exact element — see Editing your app.
• Answer MeDo's question. If a request is ambiguous MeDo asks first. Reply to the question rather than re-sending the original message.

#Templates to copy and adapt

Replace the parts in brackets. Each one follows the five-part formula.

A website for a business

A [number]-page website for [business name], a [what the business does] in [city].
It is for [who visits] looking for [what they want], mostly on their phone.
Pages in order: [Home with a headline and one call to action], [Services with prices],
[About with a photo and a short story], [Contact with address, phone, a map, and a form].
The contact form saves messages so I can read them in the admin page.
Look: like [reference site or brand] — [background colour], [one accent colour], [font feel].

A booking or ordering app

A booking app for [business], for customers who want to [book / order / reserve] without calling.
Customers choose [a service], [a person or item], and [a date and time], then enter their name and phone.
Bookings are saved; I sign in to an admin page to see them in a list and mark them done or cancelled.
Booked slots are greyed out so two people cannot take the same one.
Pages: Home, [Services], Book, Contact, Admin.
Look: [reference], [colours]. Mobile first.

An internal tool or dashboard

An internal tool for [team] to track [things — orders, leads, tickets].
Only signed-in team members can use it. Each [thing] has: [field 1], [field 2], [status: new / in progress / done].
Main page: a table of all [things] with search and a filter by status.
Detail page: edit any field, add notes, change status.
Dashboard page: counts by status and a chart of [things] created per week.
Look: plain and fast, like a spreadsheet — white background, small text, no decoration.

#Common mistakes

#Checklist before you send

• Does the prompt say what it is, who it is for, which pages it has, what data it keeps, and how it should look?
• Did you name a real reference instead of only adjectives?
• Did you say what you do not want for the things you care about most?
• Is the text real — headlines, prices, addresses — not placeholders?
• After sending: did you read the requirements document before clicking Generate App?

Still not getting what you meant? Fix the requirements document and generate again rather than patching the finished app one message at a time.