A strong app-building prompt is closer to a compact product brief than a list of technologies. It tells Squid what the user needs to do, which information matters, and how the result should feel.
The four useful layers
- Product context: audience, use case, and the primary job.
- Information: the data, labels, and hierarchy the interface must show.
- Behavior: controls, transitions, validation, and success or empty states.
- Direction: density, typography, color, references, and responsive priorities.
Prompt anatomy
Turn those four layers into a complete prompt without over-specifying the code.
Read guideStarter apps
Copy adaptable prompts for approachable first projects.
Read guideLanding pages
Build specific public pages grounded in a real offer and audience.
Read guideProduct tools
Start with richer dashboards, portals, and operational workflows.
Read guideWhat to leave out
You rarely need to prescribe every component name, folder, CSS class, or dependency. Over-specifying implementation can force unrelated decisions before the product structure is clear.
Instead of “use seven cards in a three-column grid,” say what the user must compare and which item deserves the most emphasis. Instead of “add animations everywhere,” describe the moment where motion should clarify a state change.
Keep follow-ups testable
Use follow-up prompts to isolate one kind of change:
- Behavior: “Keep the layout unchanged; make filters update the results and empty state.”
- Content: “Keep the structure; replace generic sample data with realistic field-service jobs.”
- Visual system: “Keep the workflow; reduce border density and strengthen type hierarchy.”
- Responsive: “Keep desktop unchanged; make the detail panel usable below 768px.”
That makes each new checkpoint easier to compare with the previous one.