Vibe coding
A better vibe coding prompt starts with the customer
An example-led method for describing the people, rules and finished journey behind your app idea.
Zocri · 2 min read · Sources checked
Give the app one clear responsibility
Conversational app making starts with describing what you want and refining the result. Your first prompt becomes more useful when it names a person and an action. Instead of asking for a premium salon platform, describe a customer choosing a service and requesting a time.
Add the owner's responsibility: review the request, confirm or decline it, and see the day's appointments. The same brief now covers both sides of the business. Design preferences can follow once the purpose is clear.
Use this example as a starting point
Make an appointment request app for a small hair salon. Customers choose a service, preferred date and time, then enter their name and contact details. Show that the appointment is pending until the owner confirms it. The owner needs a private list with pending, confirmed and cancelled appointments. Do not take payments in the first version.
Add your real opening hours, service durations, capacity and cancellation rules. Say whether a customer needs an account and how they should receive a confirmation. Keep passwords and service credentials out of the brief; supply them only through the product's private setup fields.
Describe the moments that usually get missed
What should happen if a person taps submit twice? What if the owner closes a day that already has appointments? Can two staff members take different services at the same time? Write a small number of concrete rules rather than asking the tool to handle everything automatically.
Give the result a finish line: submit a request, refresh the page, find it in the owner's list, change its status and confirm that another visitor cannot see it. If payment or messaging is included, test the provider result as well as the screen.
Change one thing and preserve the rest
When improving the result, name what should stay. For example: keep the existing booking steps and colors, add a service-duration field, and use that duration when displaying available times. This makes a successful change easier to recognize and reduces accidental redesign.
Keep a short note of accepted decisions. After each change, rerun the original journey and one relevant failure case. If the result is wrong, describe the observed behavior and the expected behavior. Specific feedback is easier to act on than asking an app to feel more professional.