How to describe your app so you get back what you meant

September 21, 2026 · 5 min read

I am an esthetician. Before I built my app I had never opened a code editor, and I built the whole thing between clients over six weeks. The part everyone asks about is the code, and the code is genuinely the easy part now. You describe a screen, you get working code back.

What nobody tells you is that the quality of what comes back is almost entirely decided by how you asked. Not by clever wording. By being specific about ordinary things.

That is the skill that replaced coding for me, and it is a skill you already have some version of. If you have ever written instructions for someone covering your shift, you have done this before.

The failure that teaches everyone

Here is how it goes wrong, and it went wrong for me repeatedly before I worked out why.

You ask for something big. "Build me a client booking screen." You get back something that looks impressive. You try it, and half of it is not what you pictured, so you say "no, not like that, make it better." You get back something different that is also not right, and somewhere in the rewrite the one part that did work has quietly stopped working.

Now you are three versions deep, you cannot read the code to see what changed, and you have no way back to the version that was fine. That loop is where most people decide this is not for them.

None of that is a limit of the tool. All of it comes from asking for too much at once and never saying what you wanted kept.

Four habits that fixed it

One screen at a time. Not one app, not one feature area. One screen, and ideally one behaviour on that screen. It feels slower. It is dramatically faster, because when something is wrong you know exactly which small thing to talk about instead of hunting through everything at once.

Say what must not change. This is the one that saved me the most time and the one almost nobody does. When you ask for a change, name the parts you want left alone. "Change how the save button behaves. Do not change the layout, the colours, or anything on the client list." Without that sentence you are inviting a rewrite of things that were already finished.

Ask for the plan before the code. Say "before you write anything, tell me in plain words what you are going to change and which parts of the app it touches." Then read it. If the plan is wrong, you correct a paragraph. If the code is wrong, you are unpicking work. A plan costs you thirty seconds and catches the misunderstanding while it is still cheap.

Describe the symptom, not the fix you imagined. When something is broken, resist diagnosing it. You are not the one who can see the code. Say what you did, what you expected, and what actually happened. "I tapped save on a new client, the screen flashed, and when I went back to the list she was not there." That is far more useful than "I think the save function is broken," which sends it looking in the place you guessed at.

What a good description of a screen contains

When I am asking for something new, I try to answer five things without being asked:

1. Who is looking at it. Me, or my client. These are different apps with different rules.
2. What they see when it opens. Including what they see when there is nothing there yet, which is the case everyone forgets.
3. What they can do on it. The two or three real actions, not every possibility.
4. What happens after they do it. Where do they land, what confirms it worked.
5. What happens when it goes wrong. No signal, empty required field, tapping save twice.

That fifth one is what separates an app that demos well from an app you can hand to a real client. It is also the thing you will never think of at the moment you want the feature, which is why it helps to have it as a habit rather than an inspiration.

You are allowed to say you do not understand

This felt embarrassing for about a week and then became normal. If you get back an explanation full of words you do not know, say so. "Explain that to me like I have never done this before, and tell me what it means for what my clients will see."

You are not being a nuisance and you are not slowing anything down. A thing you do not understand is a thing you cannot check, and you are the only person who knows what this app is supposed to do.

Keep your description written down

Somewhere outside the conversation, keep a plain description of your app. What it is, who uses it, the screens it has, the rules that matter. Mine started as a note on my phone between clients.

You will paste pieces of it constantly, every time you start fresh. It is also the thing that keeps the app coherent, because you are the only continuity it has.

None of this is technical. It is describing your own work clearly, which as a solo business owner you have already been doing for years. If you want to see what the rest of the process looks like, this is what the six weeks actually contained, and there is a free walkthrough of the first steps if you would rather start than read about starting.