UI

Every screen in StartupBuilder is drawn from one catalog of Components, styled by a Theme. A screen is data, a list of Components with props, and three renderers turn it into HTML, JSON and Markdown.

Design is dataCopy Anchor Link

A Page or an App screen names Components and fills their props. It holds no markup and no CSS. platewise.app, a meal-planning subscription that takes reservations before it ships, opens its home Page with four Components:

<Hero headline="Dinner planned for the week, groceries in one tap" offer="family-plan" />
<Features product="meal-plans" />
<Reserve offer="family-plan" />
<PriceTable product="meal-plans" />

Props are literal values or record ids, never code. A Page that passes the wrong type fails its check before it renders. A fix to PriceTable reaches every Site that places it on the next request.

The same rule holds for an Agent. It chooses Components and fills props from records; it never writes HTML. A thousand Sites built this way share one set of Components to fix, not a thousand codebases.

One catalog for three kinds of screenCopy Anchor Link

Sites, Apps and Dashboards share the catalog. Navigation and Footer frame a Site and an App alike, and DataTable lists records in an App and in a weekly review.

The component catalog lists every Component with its props and renderers.

Three renderersCopy Anchor Link

Every Component lowers to a small fixed kernel: text, numbers, lists, tables, media and controls. The renderers know only that kernel, so a new Component needs no renderer work. Here is one MetricTile on a clinic-scheduling Dashboard:

<MetricTile metric="weekly-active-clinics" window="week" />

The markdown renderer gives an Agent one line in its context:

Weekly active clinics: 184 (+12 vs last week, inside noise band) · as of 09:40

The native renderer gives a phone, a watch or a TV the same facts as JSON:

{ "component": "MetricTile", "metric": "weekly-active-clinics", "value": 184, "delta": 12, "band": "inside", "asOf": "2026-10-22T09:40:00Z" }

The web renderer draws it as HTML. Every interactive Component renders a static still first, so a Page works without JavaScript and an Agent reads what a person sees.

Installed native apps receive only data: screens, Components that lower to the kernel, Themes and routes. A new kernel primitive ships in a new app binary. Renderers covers token budgets, tiers and parity tests.

Verbs become controlsCopy Anchor Link

VerbSheet turns one Verb into fields and a button. Its inputs become fields, and its Mode, Price and any Approval show beside the button.

A reader sees only the Verbs their Permissions allow on that record now. Nothing is hidden with CSS.

ActionStatus shows what happened next. Each pending reason, from queued to awaitingInput, has exactly one rendering; a missing rendering fails the build. A refused Action shows its fix and the next step.

ApprovalSheet binds approve or refuse to exactly what the reader saw. If the Action changes before the click, the Approval goes stale and asks again.

ThemesCopy Anchor Link

A Theme is a Brand's design tokens: color, type, spacing, radius and motion. Every Component reads them when it renders, so one token change restyles every Site and App of that Brand. A Theme that fails contrast checks is refused at its Change.

A Studio sets the floor every Theme in its Portfolio inherits: the type scale ratio, contrast minimums, motion ceilings and radius bounds. Each Brand derives its own face on that floor, its palette, type pair and logo, and may only tighten it. A Startup writes only the tokens it changes, in brand/theme.mdx.

Your own ComponentsCopy Anchor Link

A Startup adds Components at components/[Name].mdx, with the web rendering beside it in components/[Name].tsx. Each declares typed props, a fixture, and a golden output per renderer. A Component that does not lower to the kernel, or whose renderings disagree on a fact, fails its check.

Once it passes, every Site and App of the Startup places it by name.

Design system covers Templates and the design gate in SiteBuilder.

SlotsCopy Anchor Link

An App compiles its screens from its Personas and their Permissions, and names a slot in each, such as record.aside or list.empty. A Component placed in a slot replaces that one part; the rest keeps compiling. The App lists every slot and what it binds.

NextCopy Anchor Link

• Component catalog: every Component, its props and renderers.
• The App: how an App compiles its Dashboards, Flows and slots from Personas.
• Views and dashboards: how one view per scope compiles from records.
• Abstractions: where the UI sits among the five abstractions.