Good vs. weak app descriptions
3 min
Concrete app descriptions land cleanly; vague ones leave placeholders the user has to fill in.
Weak: "A todo app." The planner has nothing to work with — no entities, no auth model, no archetype cue. Result: a generic Task model, a single page, and lots of empty space.
Better: "A solo todo app. Each Task has a title, status (todo/doing/done), priority (low/med/high), and an optional due date. Show all tasks on the home page grouped by status. SQLite, no auth." Now the planner knows: solo-practice archetype, one entity, two enums, a specific home-page layout. The generated app is usable on first run.
Weak: "A CRM." No entities named, no specific use case.
Better: "A CRM for tracking sales pipelines. Entities: Contact (name, email, company), Deal (title, amount, stage, contact). Stages are open/won/lost. Show deals on a kanban grouped by stage." The planner picks system-of-record, generates Contact + Deal models with the relationship, an admin page per entity, and a kanban dashboard for the deals.
Live recipes need the desktop
This article is a static preview. The in-app Help sidecar inside Avery NXR can fire each step against your live project — install the desktop to use it interactively.