Generative UI flips the contract: instead of the user mapping their intent onto your screens, the interface assembles itself around what they are trying to do right now. The first move is to stop answering in walls of text and start answering in real widgets. We build that on Google's GenUI SDK - officially alpha, the right primitive to start with - and add the governance, evals, and design system that make it shippable.
The answer to "who decides what the AI is allowed to render?" - you do. We define a catalog of approved, composable components and a schema the model has to compose within, so generation is bounded to interfaces you signed off on.
The model emits structured output against your schema; the layer maps it to a native widget tree and feeds interaction state back so the interface refines within the session. It is LLM-agnostic - any model that returns structured output drives it, so you are not locked to one provider.
Because the generated UI renders through Flutter, the same build runs on mobile, web, and kiosk. One generative layer, one design system, native rendering everywhere - instead of rebuilding the dynamic interface per platform.
Generated interfaces are non-deterministic, so they get the same discipline as the rest of the product: an eval harness that scores what the model assembled on real cases, guardrails on inputs and outputs, and observability that records what was asked and what got rendered - so a prompt change cannot silently regress the UI.
The entry point is one fixed-scope pilot on a use case that matters - a defined catalog, the GenUI layer wired onto your existing model investment, and a working generative interface you can judge - not an open-ended research engagement.
We pick one real use case where answering in widgets clearly beats answering in text, and tell you in writing where generative UI will earn its place and where a fixed screen is the honest call.
We design the governed widget catalog and the schema the model composes against - the set of components the AI is allowed to render, and the contract that keeps generation inside it.
We build the layer on Google's GenUI SDK in Flutter, connect it to your model, and get the loop running: structured output in, native widgets out, interaction state back.
We stand up the evals and guardrails, run the generated interface against real cases, and close the ones where it drifts - so what ships is measured.
The pilot goes live and the code is yours - the catalog, the schema, the evals, documented Flutter your team can extend and re-run the evals against without us in the loop.
Google's GenUI SDK is new and officially alpha - no production case exists yet, ours included, and we will tell you that plainly rather than imply otherwise. What is real: the governed-catalog pattern, the evals-for-generated-UI approach, and the Flutter delivery layer are the same discipline we apply everywhere else we build.
It's genuinely alpha, and we say so rather than hide it. What makes it safe to start on now is that the governed-catalog pattern, the evals, and the Flutter delivery layer we build around it don't depend on the SDK's API surface staying fixed - they're the discipline layer around it.
The model composes only from a catalog of components you define and approve - it cannot render anything outside that catalog. The schema is the contract that keeps generation bounded to interfaces you signed off on.
One Flutter codebase renders the generated UI on all three - one generative layer, one design system, instead of rebuilding the dynamic interface per platform.
One real use case, a defined widget catalog, the GenUI layer wired onto the model you already use, and a working generative interface you can judge at the end - fixed scope, not an open-ended research engagement.
The same way we keep any AI feature honest: an eval harness scores what the model assembled against real cases, so a prompt change that regresses the UI gets caught before it reaches a user.
Send the screen your model keeps describing instead of building. A founder reads it and replies within 24 hours.
Read our case studies