Getting started
How to write effective Div-idy app prompts
A useful Div-idy prompt explains who the app serves, what users do, what result they receive, and where information belongs. Add design preferences after the core behavior. For edits, name the page and describe the specific change while identifying working features that should remain intact.
What should an app prompt include?
- Audience and purpose: who will use the app and why.
- Interaction: the fields, buttons, choices, and screens they need.
- Result: what appears or happens after each important action.
- Data: whether information stays on a device, reaches the owner, or becomes public content.
- Design: colors, tone, layout, and mobile priorities.
Describe observable behavior. “Show a clear error beside an empty required field” is more useful than “make it professional.”
Example: a prompt with a complete user journey
Build a React meal-planning tool for busy households. Let users choose three dinners from a fixed recipe list, adjust servings, and see a combined ingredient list. Save the selection on this device and include a reset button. Use a compact green-and-cream design, large mobile controls, and readable ingredient quantities. This version uses the supplied recipes and does not need AI or visitor accounts.
This request gives Div-idy a defined interaction, storage choice, and finish condition. Add your actual recipes or business content when correctness depends on them.
Be explicit about data and integrations
Ask for a real project-database submission when a contact form should reach you. Ask for owner-managed draft and published records when you need to maintain a catalog. Ask for text AI, image generation, speech, or maps when those actions are part of the product.
Private visitor accounts, personal cloud-synced records, arbitrary package installation, and custom server jobs are outside the standard generated-app runtime. Describe a supported first version when an idea depends on those features.
How do you request changes without losing direction?
Open the intended page before editing. Name the current behavior, requested behavior, and what to preserve: “On the recipes page, add a vegetarian filter above the cards. Keep serving adjustments, saved selections, and existing navigation.”
Group closely related changes together. For a broken interaction, include the steps, actual result, and expected result rather than asking for a general redesign.
Give the build a practical completion checklist
Specify two or three checks: empty search shows all recipes, changing servings updates quantities, and selections return after a refresh. Run those checks in the finished draft. Refine from what you observe, then publish after the intended journey works.