Writing a good brief
What to put in your first message and in follow-ups so the builder gets it right the first time.
Last updated September 17, 2026
On this page
The builder is good at filling gaps, but the gaps it fills are the ones you would rather have decided. A brief that answers four questions gets a first build that is close to right.
The four questions
Just you, your team, or your customers. This decides whether the app needs accounts at all, and whether strangers may sign up.
The two or three core things and their important fields: classes (name, teacher, time, spots), bookings (member, class, paid).
The one workflow that has to work on day one: a member picks a class and books it.
A reference in a few words: calm and minimal, bold and playful, serious, like a bank. Or name a site whose feel you like.
An example
A booking website for my yoga studio. Visitors see the weekly schedule and the teachers without signing in. Members sign up with email or Google, book a spot in a class, and get a confirmation email. I am the admin: I add classes and see who is booked. Calm, warm, plenty of white space.
Follow-up requests
- Point at the thing: "on the schedule page, the Book button" rather than "the button".
- Describe the outcome: "members should see only their own bookings" rather than proposing code.
- One change per message. You can queue several.
- Attach a picture when words are slow: a screenshot with a circle on it, or a sketch.
- Say what stays: "keep everything else as it is".
What you do not need to say
Colours, copy, minor fields, empty states and loading states are all decided for you and stated in one line so you can change them. You never need to name a library, a framework or a file. The builder chooses its tools and tells you what it did in plain words.