The starting point: a designer, not a blank page
A generated application starts from one of a hundred curated designer profiles — each a real design reference cited as such, not a generic theme. Picking a profile at generation time means choosing an intent (dense and functional, airy and editorial, dark and high-contrast…) instead of starting from an empty branding form to fill in field by field.
That choice stays adjustable afterwards: duplicating a curated profile as a starting point, then tuning it, is the normal path — not an exception.
Your charter: colours, typeface, density — and beyond
The first level of adjustment is the expected one: an eight-colour palette (accent, structural materials, ink, backgrounds), a typeface, a corner radius, a spacing density. These tokens drive the whole generated interface, not one isolated page.
A second, less visible but real level goes further: typographic scale and weight, title casing, surface treatment (elevation, border, contrast), the composition of structural blocks (card, sidebar, header), transition motion, layout width, a dedicated dark palette, and deliberately expressive title treatments (colour block, coloured drop shadow, italics). Every setting in this second level is optional: leaving it blank returns exactly the behaviour of the chosen designer profile — nothing degrades by default.
Navigation is adjusted afterwards, without regenerating anything
Sidebar labels, their order, and page titles aren't fixed at generation time: they can be customised from the application's settings, once deployed, without re-running a full generation. It's a global, persisted setting for the application, not a per-user preference.
That's a practical difference from "regenerate to rename a menu": the adjustment targets exactly what needs to change, instead of reopening the whole application plan.
What isn't adjustable by hand, and why
Component props and the deterministic layout (which data goes into which screen type, how a table or a dashboard assembles) aren't exposed settings: they're set by the generator, not by you. That isn't a temporary limitation — it's the same doctrine as the rest of the product: technical conformity is guaranteed by construction, never left to a setting that could produce a broken screen.
A guard also exists for colour itself: only one accent colour is allowed per application. A second bold colour used as a decorative fill is detected and repaired automatically. That isn't an arbitrary constraint — a charter fighting over two competing accents is the most common visual defect of improvised customisation, and the application avoids it by construction rather than relying on anyone's vigilance.
How to actually go about it
When generating: pick a designer profile close to the intent you're after, or leave the default profile if visual identity isn't a priority yet — it can be adjusted afterwards at no cost.
Once the application is deployed: adjust the charter (colours, typeface, density) for the first-level identity, then, if needed, the structure settings for the details that make the difference — without ever touching the screens' own code, which stays exactly what the generator validated.