Describing your app

How to write the description so the prototype comes back close to what you meant, and how to correct it when it does not.

The first description does more work than any other input. It decides who the app is for, what the first screen is built around, and which screens exist at all. This page is about writing it well, and about the fastest way to correct it when it lands wrong.

Say who it is for and what they are trying to do

Mistflow builds around jobs: when something happens, someone wants to do a thing, so that they get an outcome. A description that names the person and the moment produces a much better first screen than one that lists features.

A booking app for a two-chair barbershop. Regulars pick a barber and a
time, see their upcoming appointment, and get reminded the day before.

That is enough. It names the user (a regular), the moment (booking a slot), and the outcome (showing up at the right time).

Compare it with a feature list:

An app with a calendar, a profile page, notifications, a settings
screen, and a booking form.

The second version produces a competent, generic app. It has no opinion about what the first screen should be, because you did not give it one.

One app, one audience

Every app has a main user. A barbershop app has customers; the barber who runs the shop is a different audience with different needs.

Mistflow builds the customer app first, and offers the owner side as a separate console you can open when you want it. That is deliberate. Apps that try to serve both audiences on the same screens serve neither well.

So describe the customer's app. If your app has an operator, mention them and let the console handle it:

...and the barber needs to see the day's schedule and block off time.

Say what makes it yours

The parts worth spelling out are the ones a generic version of your app would not have:

Rules: "a slot can only be booked once", "only the person who created a trip can invite others"
The number that matters: a streak, a balance, days remaining, distance covered
What people see first: "open on today's schedule, not a menu"
Tone: "warm and playful, not corporate"

Things you can leave out, because they are asked later or handled for you: the database, sign-in mechanics, screen sizes, navigation structure, and which libraries to use.

Length

Two to five sentences is the sweet spot. Long descriptions are not penalised, but past a certain point extra detail is better delivered as an edit to the prototype, where you can see what it did.

Examples

A running app called Pace. Runners log a run, see the week's distance
against a goal, and get a streak for consecutive weeks they hit it.
Home screen opens on this week's progress. Calm, dark, data-forward.

When the prototype comes back wrong

Do not rewrite the description and start over. Correct it in place, which is faster and keeps everything you liked:

What is wrong	What to say
Wrong emphasis	"Make the streak the biggest thing on the home screen"
Wrong audience	"This is for the customer, not the shop owner"
Missing screen	"Add a screen for past orders"
Too much	"Drop the settings screen"
Wrong feel	"Warmer, less corporate. Softer corners"

See Shaping the prototype for everything you can change and how quickly each change lands.

Asking for things that are not supported

Mistflow declines rather than pretending. If you ask for in-app subscriptions on a phone app, or real-time multiplayer, you get a straight answer instead of a screen that looks right and cannot work. The list of what is and is not supported is in What your app can do.