Solar Use Cases
Solar is designed for apps where an AI agent writes the UI, not a human. The explicit contracts, rigid file structure, and declared side effects make agent output reliably correct — not just probably correct.AI-generated internal tools
The strongest fit. A business user describes what they want (“show me overdue invoices with an approve button”) and an agent generates the components. Solar’s prop schema gives the agent an exact contract to target — no guessing, no runtime surprises from a mismatched prop type. Why Solar specifically: internal tools get regenerated frequently as requirements change. A human isn’t reviewing every generated file. Contracts catch errors at the boundary before they propagate.No-code / low-code builders
Platforms where a visual config or user input drives component generation on the backend. Solar gives the generation layer a strict, machine-readable schema for every component — the platform always knows what a valid Button or Form looks like. Why Solar specifically: the component registry and slot system let the platform compose components predictably without knowing their internals.Vibe-coded apps
Apps built entirely through prompting — Cursor, Claude, or similar tools writing the full codebase. Solar reduces the “worked in isolation, broke in context” failure mode that comes from AI generating components that don’t share conventions. Why Solar specifically: one component per file, default export always adefineComponent call, event handlers always typed as function. Rules a model can follow without inference.
Configurators and form builders
AI generates a custom UI from a data schema, API spec, or JSON config. The output is a set of Solar components wired together — predictable, validatable, and regeneratable. Why Solar specifically:useResource and declared effects make async data fetching machine-readable. The agent knows exactly how to wire a fetch to a component without guessing at lifecycle behavior.