Write your first prompt
Give Ahamo enough product, user, behavior, and design context for a useful first version.
On this page
A strong first prompt explains who the app is for, what they should accomplish, and how the result should feel. It does not need to describe every screen or future feature.
Include four decisions
What you are building
Name the product and its audience.
A booking page for a small bicycle repair shop, used mainly by local customers on their phones.
The main journey
Describe the action from beginning to end.
A visitor chooses a service, selects a preferred time, enters contact details, and sees a confirmation.
Important content and states
Mention information Ahamo cannot safely infer.
Show service duration and price. Explain what happens after a request. Include a helpful state when no times are available.
Visual direction
Use a few specific constraints instead of “make it modern.”
Calm workshop feel, navy and warm white, one orange accent, large readable type, and no stock-photo hero.
Put it together
Build a booking page for a small bicycle repair shop, used mainly on phones. Visitors should choose one of three services, see duration and price, select a preferred day and time, enter their name, email, and phone number, and receive a clear confirmation. Include a helpful state when no times are available. Use a calm workshop style with navy, warm white, one orange accent, and large readable type. Start with this booking journey; do not add accounts, payments, or an admin dashboard yet.
This is enough direction for a first build while leaving room for Ahamo to propose a coherent interface.
Make later prompts focused
Ask for one outcome at a time:
Add a private staff page that lists bookings by day. Reuse the current service names and visual style. Plan the data and access rules first. Do not change the public booking journey.
When something is wrong, describe what you observed:
On mobile, the appointment form shows every field at once and the submit button is difficult to find. Group the contact fields, reduce unnecessary vertical spacing, and keep the submit action visible. Keep the questions and desktop behavior unchanged.
For a failure, include the action, expected result, visible result, and environment:
In production, submitting a valid booking returns to the form without confirmation. The same journey works in Build. Investigate the difference and identify the smallest correction. Do not change the app yet.
Use Plan when you want an explanation before Ahamo changes the app.
Before you send
Check that:
- you can name the person and outcome;
- the prompt has one primary journey or change;
- required content and meaningful limits are explicit;
- you can test the result after one build.
Use realistic fictional examples while designing. Do not paste passwords, provider secrets, confidential customer data, or unpublished business records into a prompt. If wording has legal or commercial meaning, provide approved copy and ask Ahamo to preserve it.
Next: Move from idea to first milestone or build and publish your first app.