How to Write Prompts for AI App Builders

In the last guide we walked through the three phases of building something: skeleton, function, polish. This one is about the bit that happens inside all three — actually talking to the tool.

Because here's the odd thing about modern no-code. There's no code to write, no syntax to memorise, no menu of commands to learn. There's just a text box, and whatever you type into it becomes your app.

That sounds easy, and in a way it is. But it also means your words are doing all the work. The picture in your head only becomes a real screen to the extent that you managed to describe it. Which is why the same tool, in two different pairs of hands, produces two very different results.

The good news is that describing things well is a learnable skill, and it takes about an afternoon to get decent at it.

Most people's frustration with these tools comes from one wrong assumption: that you're supposed to get it right in a single prompt.

You're not. It's a conversation, not a command. You describe what you want in ordinary words, the tool builds it in seconds, you look at what came back and decide what's off, and you adjust — and it builds again.

Your first result is a rough draft. Treat it as clay rather than a verdict, and everything gets easier — you stop agonising over the perfect opening prompt and start shaping something that already exists, which is far more natural anyway.

The first one carries more weight than the rest, because everything after it is built on top. Not because it has to be perfect — because it sets the foundation everything else sits on.

Aim to describe the heart of the app, not every detail. There's time for details later. What you want to get across is what the thing is, who it's for, and the two or three things people should be able to do with it.

A simple way to shape that: who is going to use it, what it helps them do, and why it's worth having.

Three sentences. Who it's for, what it does, why it matters. That's genuinely enough to start.

A note on planning modes. Most builders now offer some version of "talk it through before you build" — a mode where the tool asks you questions and turns your answers into a plan you can adjust before anything is made. If yours has one, use it. It's the cheapest way to find out that you hadn't quite decided something.

The gap between a disappointing result and a good one is almost always about how much of the picture you shared.

Anything you leave out gets filled in with a guess. Sometimes the guess is fine. Often it isn't. The more concrete you are, the less there is to invent.

Vague: "Make a dashboard for my sales." Clear: "Make a sales dashboard with three cards along the top showing total revenue, deals won and deals lost, then a bar chart below showing revenue by month."

The second one takes twenty extra seconds to write and saves you three rounds of corrections.

This one surprises people. Explaining your reasoning helps the tool make sensible decisions about all the things you didn't mention — and there are always things you didn't mention.

Just the what: "Put the sign-up button at the top." With the why: "Put the sign-up button at the top so it's the first thing a new visitor sees."

The second version tells it something about the button's importance, which quietly influences its size, colour and spacing too.

You don't have to describe a look from scratch. Naming something familiar is a shortcut to a whole set of decisions — as long as you say which part you mean.

"Organise it like a Trello board, with cards I can drag between columns." Or: "Make it feel as calm and uncluttered as Notion, but keep my own colours."

"Make it like Airbnb" is too broad to be useful. "Use Airbnb's card layout for the listings" is a real instruction.

This is the big one, and it echoes the phase approach from the last guide.

Cramming an entire app into one prompt gives you a result that's harder to get right and much harder to fix, because when something's wrong you won't know which part caused it.

Build the core. Get it working. Then layer things on, one at a time. Three small prompts beat one large one nearly every time. They're also usually cheaper, since most tools charge by the work done and a narrow change is less work than a broad one.

When something looks wrong, the instinct is to describe what's wrong. But the tool builds towards a target, and "this is bad" isn't a target.

The flaw: "The homepage looks cluttered and cramped." The fix: "Give the homepage more room to breathe — fewer items per row and more space between the sections."

Same complaint, but one of them can actually be acted on.

When the design matters, describe three things together rather than one. Each covers a gap the others leave open. Push past "clean" and "modern", which are so common they mean almost nothing.

Once the app exists, most of your time goes into adjusting it. These phrasings are reliable, and each one gets sharper with a small addition.

That last framing is worth adopting generally. Describing features as things people can do tends to produce better results than describing them as things that should exist.

Typing isn't always the fastest route. Most builders give you a few other ways in, and they're often more precise than words.

Point instead of describing — if there's a way to click directly on an element and edit it, use it. "This one, not that one" is much easier to click than to explain, and in many tools these direct edits are free.

Talk before you build, since discussion or planning modes let you agree on an approach before anything changes in your actual app. Show rather than tell: if you already have a design, importing it beats describing it. Set your rules once, in whatever place stores standing instructions — brand colours, tone of voice, things never to touch. And know how to go back: find the version history before you need it. Knowing you can undo anything is what lets you try bolder ideas.

Some rounds just don't go well. Rephrase rather than repeat — saying the same thing louder rarely works. Come at it from a different angle, and use stronger words like "redesign" or "rebuild" when a small tweak clearly isn't landing.

Point instead of typing if a change keeps hitting the wrong element. Constrain what can change if other parts of your app keep getting altered. Go back and try a different route: if you're three rounds deep and it's getting worse, restore an earlier version and approach it differently. Sunk cost is real, and undo is free. And check whether it's even possible — occasionally the answer is that the feature isn't supported yet, which is worth finding out before another hour disappears.