Screens
Another screen for each intent
Transactions, filters, analytics, budgets, recommendations — each lives on its own path.
Generative UI for apps you already shipped
Stop building a new flow for every user intent.
Bring the power of AI into the product you already run. AppSana understands what the user is trying to finish, then builds the UI on the fly from your design system — widgets, tools, and actions you already own — so tasks complete faster than walking a menu.
Live example
Ask BankSana to rearrange itself.
This is a demo super-app home — banners, services, cards, transfers, and products. Ask it to shop or send a transfer and the matching widgets move to the top.
9:415G
BankSana
Hello, User
BankSana · Adaptive super-app
Last transfers
For you
The problem
Users have more intents than you can design screens for.
A production app already has screens, APIs, business logic, and a design system. Every new intent still becomes another screen, another navigation path, another edge case — and another thing product and engineering have to maintain. The app gets more powerful. It also gets harder to use.
Navigation
Users have to learn the IA
The shortest path to the outcome is rarely the one the information architecture suggests.
Maintenance
Every flow is a permanent cost
More states, more edge cases, more design and engineering work every time a new intent appears.
Reuse
Tools stay buried
The APIs and widgets already exist. Users still have to assemble the journey themselves.
The shift
Stop asking which screen the user should visit. Ask what they are trying to do.
Traditional product design maps intent onto navigation. AppSana maps intent onto the widgets, tools, and actions you already have — and builds the screen that finishes the job.
TODAY
The user adapts to the app
Fixed screens. Fixed flows. The user has to learn your information architecture.
- →User intent
- →Hunt through navigation
- →Open the right screens in order
- →Run the tools, if they find them
WITH APPSANA
The app adapts to the user
Intent plus on-device context. The SDK runs your tools, then generative UI assembles the widgets that belong on screen right now.
- →User intent
- →SDK runs the relevant tools on device
- →Generative UI assembles widgets from your design system
- →User reaches the outcome
Context, through tools
The screen follows what is true right now — not a static home.
AppSana does not invent tools the app did not expose. The host runs those tools locally, then the runtime prioritizes widgets from your design system around the result. Context is how generative UI knows what to put on top.
BANKING
A balance due jumps to the top
If a tool reports an unpaid amount, AppSana does not wait for the user to open Bills. It tells the SDK to prioritize the due widget — amount, due date, and the pay action you already shipped.
get_balance_due → prioritize PayBill widget
TRAVEL
A flight today becomes a boarding pass
If a tool says the user flies today, the home is not a generic catalog. The runtime surfaces gate, seat, and boarding time with the widgets your travel design system already has.
get_todays_trip → show BoardingPass widget
Security
The LLM never needs the user's private data to change the UI.
AppSana sends structure, not secrets. The model sees the JSON widget tree shape, the tools you registered, the actions the SDK can run, and the widgets in your design system. It returns instructions to the app SDK — patches and tool calls — for how the screen should change. Balances, card numbers, tickets, and identity stay inside the app. AppSana servers and the LLM do not receive that payload.
THE MODEL SEES
- ▸JSON structure of the current UI — widget types, ids, and layout
- ▸Tools available on the device, as schemas, not their private results
- ▸Actions the SDK is allowed to run
- ▸Widgets from your design system that can be composed
- ▸Instructions back to the app: how to patch the tree or invoke a tool
WHAT STAYS IN THE APP
- ▸Balances, card numbers, tickets, and identity records
- ▸Tool execution — fetch, pay, search — runs inside the host app
- ▸Raw tool results, unless you explicitly choose to send a field
- ▸Nothing sensitive is required by AppSana servers or the LLM to change the UI
Personal screens
Let each user construct the home they actually need.
Generative UI is still new. Most apps still ship one layout for everyone and hope the next release covers the next intent. With AppSana, a customer can pin transfers, hide cards, surface travel, or rebuild a personal screen from your widgets — without you designing a settings panel for every preference.
That is a product advantage, not a theme toggle. Teams that adopt generative UI first will finish more user tasks inside the app they already have — and pull ahead of companies still adding another tab.
Their layout
Pin transfers, hide cards, lift travel — a home that matches how that person actually uses the app.
Your widgets
Every block still comes from the design system you shipped. Generative UI rearranges; it does not invent a new brand.
First-mover edge
Most competitors will still ship another screen. You can let customers construct the product around themselves.
How it works
Build the app once. Let AI assemble the experience.
Developers stay in control of what is possible. AppSana sits between your UI state and an LLM, then tells the SDK which widgets to show and which of your tools to run.
YOU PROVIDE
Widget library
The screens and components you already designed — including contracts your design system already uses.
Tools and actions
What the application can actually do: get_balance_due, get_todays_trip, start a transfer. Executed by the host app, never by the model.
UI structure
The current widget tree as JSON shape. The model reasons over types and ids, not over the user’s private records.
APPSANA HANDLES
Intent understanding
Reads the request against the current UI, available widgets, and tool schemas.
Tool selection
Chooses which of your tools to invoke — and never runs code the app did not expose.
UI instructions
Tells the SDK how to change the tree: move a widget, hide a section, or place a boarding pass on top.
Ship the SDK
Init the runtime. Place the view. Keep the design system.
Drop BduiView into any Compose layout — a full screen, a tab, a card, or beside native widgets. The host renders those widgets, executes tools, and applies the instructions AppSana returns. Your binary stays the source of what the product can do.
Bdui.init(
BduiConfig {
httpClient = appHttpClient
appsana = BduiAppsana(
url = "https://appsana-platform.vercel.app/api/bdui",
apiKey = appsanaApiKey,
applicationId = applicationId,
)
},
)
@Composable
fun HomeScreen() {
BduiView(
initialJson = homeJson,
modifier = Modifier.fillMaxSize(),
)
}
BduiAppsanaClient(config, runtime)
.transform("Show my boarding pass")Who it's for
Teams that already have a successful app.
CTOs, heads of mobile, and product leaders with hundreds of screens, APIs, and established flows. AppSana is a generative UI layer on top of that investment — for fintech, e-commerce, marketplaces, travel, telecom, and super apps.
Fintech
“Help me understand where my money went.”
A due-balance tool, categorized spend widgets, and the transfer the user can actually make — composed, not a five-screen tour.
E-commerce
“Find me everything I need for a weekend trip under $300.”
Catalog, cart, and budget tools already in the app, assembled around the trip instead of a search box.
Travel
“I need to get home tomorrow morning with as few connections as possible.”
Search, inventory, and booking tools you already operate, ranked for that constraint — plus today’s boarding pass when a flight exists.
Food delivery
“I'm hosting 8 people tonight. Help me order dinner.”
Restaurant list, party size, dietary filters, and checkout — one task, not a browse session.
Telecom
“My internet is slow. Check my plan and help me fix it.”
Plan details, diagnostics, and the support actions the app already exposes.
Marketplaces
“I need a plumber who can come today.”
Search, ratings, availability, and booking — tools the marketplace already has, composed around urgency.
Be early. Let users finish in your app, not a competitor's.
Expose widgets, tools, and actions. Let generative UI assemble the screen that matches the moment — using the design system you already trust.
Start building