Component Architecture

Every generated project follows the same shape, so you can move between apps — or hand one to a teammate — without re-learning the layout. Knowing this shape also makes your prompts sharper: you can point at exactly the layer you want changed.

Frontend layout

• src/components/ — small reusable pieces (buttons, cards, form fields).
• src/pages/ (or src/routes/) — top-level screens, one file per route.
• src/services/ — a typed API client, one method per backend endpoint.
• src/store/ — state container (Zustand for React, Pinia for Vue, and so on).

Backend layout

• routes/ — HTTP entry points; thin handlers that delegate.
• services/ — business logic, kept out of the routes.
• models/ — DB schema, matched 1:1 with frontend types where possible.
• middleware/ — auth, request logging, error normalization.

Talking across the boundary

• Matching TypeScript types are generated on both sides where the language allows.
• Rename a field in the model and the frontend service signature and form bindings regenerate with it — you rarely fix the "other side" by hand.

Use the structure in your prompts

• Be precise: "add a reports service and a matching page", or "move the tax calculation from the route into a service".
• In the desktop editor, @-mention the exact file to remove any ambiguity.
• Ask for structure-improving refactors: "split this controller into a route and a service".

Common mistakes to avoid

• Putting logic in routes or components. It works at first but gets hard to change — keep it in services/.
• Letting one file grow unbounded. Ask the AI to split it once it passes a few hundred lines.
• Editing generated types by hand. Change the model instead and let both sides regenerate.

FAQ