Release
Prototypes are now composed by Thinkr, not improvised by the model
Prototype screens are assembled by the backend from a component library — the model supplies the content, Thinkr lays it out — so every screen is consistent and correctly structured. No more marketing hero banners on a dashboard.
The biggest reason generated prototypes looked inconsistent was that the model authored every screen's layout from scratch — so the same prompt could put a giant marketing hero on a dashboard, or arrange two screens completely differently. We've moved that decision into Thinkr.
The backend now owns the layout
Each screen is now assembled from a component library — stat rows, data tables, lists, detail grids, form cards, hero bands, confirmation cards and more — rendered by Thinkr from the shared design kit. The model's job is narrower and what it's actually good at: choosing the right components for the screen and filling them with real content from your PRD. Thinkr does the composing.
Because the structure is owned by the backend, every screen is laid out consistently, whatever the scenario — and a screen's type constrains what it can contain. A dashboard leads with its stats and a table; a sign-up screen is a proper form card; a success screen is a focused confirmation. An app screen can no longer render a marketing hero banner, because that component simply isn't on its menu.
What you'll notice
- Consistent screens. Tables, forms, lists and cards look the same across the whole prototype — they're the same components.
- The right shape per screen. Dashboards, forms, and confirmations are structured like the real thing instead of a generic page.
- Cleaner details. List rows align correctly, sample-data labels no longer overlap tables, and long text wraps inside its card.
Chat edits work the same way — when you ask for a change, Thinkr re-composes the affected screen from components, so it stays consistent after every edit. Regenerate an existing prototype to pick this up.