Describe the behavior
Explain what a person should be able to do and what should happen next. “Let the owner confirm a booking” gives a clearer target than “make it more professional.” Separate functional requests from visual refinements when possible.
Refine in small steps
After a first version, ask for a focused improvement. Adjust a form, simplify a navigation path, or clarify a confirmation message. Review the changed area before combining it with the next request.
When a client submits a booking request, show the selected service and time in the confirmation. Make clear that the owner still needs to approve it.
Review the preview and checks
Try the app as each kind of user. Check empty states, invalid input, repeated submissions, and narrow screens. Review available build checks, but remember that a successful build does not establish that permissions, business rules, or security are correct.
Use sample data during development. Avoid including passwords, payment details, or unnecessary personal information in your prompts.
Understand version history
Atomic’s workflow includes verified source history and frontend release rollback. Returning to an earlier source version or frontend release does not restore your app’s business data. Database changes and data recovery need their own plan.
Prepare a version to share
When the core workflow is useful, work through the publishing guide. Keep a record of what you tested and the known limitations of the version you are sharing.