Loyalty · Promotions · Gamification
Ship screens, not releases.
A visual server-driven UI (SDUI) builder: your product team builds a screen in the editor and publishes it. The app shows the new screen right away — no build, no store review.
- No store release
- Your users’ data never passes through us
- SDKs for React, Flutter, iOS and Android
Live screen
Tap the screen — it’s live
What your code receives
Tap a button on the screen. Every action, analytics event and screen change arrives in your code — the document never runs anything by itself.
Not a picture: a published document, drawn by the same React SDK an app would ship.
How it works
Three steps, and none of them is a release.
Compose
A manager assembles the screen from 28 widgets on a phone-sized canvas, binds them to data your backend already returns, and sets when each part shows.
Publish
One button, for the people allowed to press it. The document is checked against the contract first; every publication is kept, compared with the draft and can be rolled back. Look at it on your phone first, and send it for approval if your project requires four eyes.
The app shows it
The reader inside your app draws the published document in your theme and your user’s language. Nothing is rebuilt, and nothing waits for a store.
Ways to run it
Where the editor runs, and where your screens live.
HotLayout has two parts: the editor, where your team builds and publishes screens, and a reader SDK inside your app that draws them. Here is where the editor runs.
Available now
HotLayout Cloud
You sign in to a workspace we host: an organisation, projects, roles, the editor, publishing and history. There is nothing to install.
Layouts, themes and media are stored in HotLayout Cloud.
With a pilot
The editor inside your admin
The same editor, embedded in your own back office as a web component. Sign-in, language and theme come from you, so your team never sees a second login.
<hotlayout-builder>Only the editor moves into your page. Layouts, themes and media are still stored in HotLayout Cloud.
On request
On your own servers
The same editor as a single static file inside your own admin, with your sign-in and your storage API. The editor makes no request to HotLayout or to Google; the licence key is checked offline.
Layouts, themes and media stay in your infrastructure. You provide the storage API; we provide the editor, the SDKs and the documentation. It comes with a licence, after a pilot in the cloud.
Either way, your app can show screens without our cloud.
Turn on the webhook, and every publication is sent to your backend with a signature. Your app then gets screens from your own servers, together with your users’ data — and none of that data passes through HotLayout.
The editor
Built for the person who owns the screen.
Not a form over JSON. A canvas, a phone and the properties of whatever is selected — the screenshots below are the editor itself, with a rewards screen open.
Drag widgets onto the phone. Style comes from your theme tokens first; a custom value is one step away when a design needs it.
What a screen can do today
Enough to build the screen your designer drew.
28 widgets
Layout, text, images, lists, grids, tabs, carousels, progress bars and rings, an app bar and a bottom navigation bar.
Data from your backend
Bind text, images and conditions to fields you already return. One template draws a whole list from a collection. Show or restyle a block when a task is locked, in progress or done — without duplicating the screen.
Themes and tokens
Light and dark themes, your own tokens, and a custom value where a token does not fit.
Places in your app
A developer marks a place once — the banner on Home, a block on a tab. From then on, marketing decides what is shown there and queues promotions with a start and an end. The app switches them by the phone’s own clock, even offline.
Review before publishing
Send a frozen version to a colleague with one link. They approve it or ask for changes. A project can require approval before anything goes live; the author cannot approve their own work.
Preview on a real phone
Scan a QR code and see the draft on your own device as you edit, before anyone else sees it.
Languages and right-to-left
Translations and plural forms in the document; numbers, dates and currency in the user’s locale; a mirrored layout for right-to-left scripts.
Actions, navigation and forms
Screens, modal layers, deep links and analytics events; text and number fields, switches and choice groups, with required fields and a button that waits for them. What an action does stays in your code.
History and rollback
Every publication is a snapshot. Compare it with the draft in plain words and bring any version back.
Roles and activity log
Owners, admins, publishers, editors and viewers: editors prepare, publishers release. The log shows who changed, approved and published what, and when; entries cannot be edited, and with a licence the log exports for an audit.
Motion that feels native
Numbers count up, progress fills, blocks fade in when a condition changes, a node floats or pulses, and a sheet slides over a blurred screen. Every reader draws it the same way; there is nothing to code.
Start from a ready app
Whole apps — gamification, a survey and more — with their screens and navigation. Copy one, replace what is yours, publish.
For developers
Server-driven UI: one component in your app, the rest is data.
The reader takes a document, a theme and your data. Navigation, analytics and whatever a button does stay in your code — the document only says which action was asked for.
A contract, not a canvas
The editor and the readers follow one versioned JSON Schema. What the schema cannot say does not exist in the editor, so it cannot produce a document your app cannot draw.
Server-driven UI SDKs for web, Flutter, iOS and Android
The same document is drawn by a React package, a Flutter package and native readers for iOS (Swift, SwiftUI) and Android (Kotlin, Jetpack Compose), all checked against shared tables of cases. The React and Flutter packages are open under Apache 2.0: npm install @hotlayout/react and flutter pub add hotlayout_flutter. The iOS (Swift Package Manager) and Android (Maven Central) readers are open under Apache 2.0 too.
Old apps, newer documents
Schema, theme and data dictionary are versioned separately. What an installed app does with a document newer than itself is decided by the compatibility policy, not by chance.
Documents are untrusted input
The reader never opens an address by itself, checks every value that becomes a style or an image source, and keeps a broken document from taking your app down.
Delivery through your backend
Each publication can be sent to your server as a signed webhook (HMAC-SHA256). Your app gets screens from you, together with the user’s data — nothing about your users passes through us.
import { HotlayoutScreen } from '@hotlayout/react'
import type { ThemeContract, UiDocument } from '@hotlayout/react'
export function Rewards({ layout, theme }: { layout: UiDocument; theme: ThemeContract }) {
return (
<HotlayoutScreen
document={layout} // the layout document, parsed JSON
theme={theme} // the project theme, parsed JSON; omit it to use the built-in one
data={{ 'user.firstName': 'Ada', 'user.points': 1250 }}
collections={{ items: [{ name: 'Coffee', price: 300 }] }}
locale="en"
style={{ minBlockSize: '100dvh' }}
onAction={(action, source) => {
console.log('the user asked for', action.type, action.params, 'on', source.nodeId)
}}
/>
)
}
POST /your-webhook
x-webhook-event: document.published
x-webhook-delivery: <documentId>/<stamp>
x-webhook-signature: t=<seconds>,v1=<hex>
{
"event": "document.published",
"documentId": "autumn-rewards",
"document": { … },
"dataContract": { … }
}
Where teams use it
Screens that change more often than the app does.
Gamification
Quests, rewards, levels and streaks — the case HotLayout was first built for.
Promotions and offers
A campaign screen that starts on the day marketing planned, and ends when it ends.
Surveys and forms
Questions, choices and inputs that write back to your app, changed without a build.
Onboarding
Steps you can rewrite, reorder and translate while the same app version is in users’ hands.
What it does not do
Honest limits.
It does not ship code.
A document describes layout, content, conditions and named actions. Logic stays in your app.
It does not fetch your data.
The reader takes data from your app and never calls your backend by itself.
It is not an animation tool.
Motion is a fixed vocabulary — fades, transitions, number count-ups — that every reader draws the same way. Anything beyond that stays in your app.
It keeps no analytics of its own.
Taps send named events to the analytics you already have. We do not see your users, and we do not run A/B tests for you — conditions on your own data do that.
Pricing
One price per app. No per-user fees.
A licence is counted by the apps that read your screens, not by the people who use them. The price depends on where the editor runs: in our cloud, inside your own admin, or on your own servers.
Pilot
€2,500
one-off, 8 weeks
A real integration into your app. On day one we write down the one sentence that means success — for example, “the promo screen is in production, and marketing changes it without a release”.
- 1 app, up to 3 screens in production
- Up to 30 hours of our work on the integration
- Credited in full if you take a licence within 30 days
Cloud
€4,800
per year for one app
The editor in HotLayout Cloud. Your team builds, publishes and rolls back the screens of one app — however many people use that app.
- Up to 10 people in the editor
- No limit on screens, publications or audience
- Roles, version history and rollback
- Delivery from our storage or by signed webhook
- SDKs for React, Flutter, iOS and Android
Embedded
€9,600
per year for one app, after a pilot
The same editor inside your own admin, with your sign-in, language and theme. Layouts are still stored in HotLayout Cloud.
- Everything in Cloud
- Up to 25 people in the editor
- The editor opens only on your domains
- 16 hours of our work on embedding and training
Want to try it yourself first? Open the sandbox — no sign-up. For a workspace where your team builds and previews screens with your own data, ask for access, and we will open one for 14 days.
Prices are per year, in euros, excluding VAT. Each further app of the same company is 30% less. People who only view and approve screens are not counted. Published screens keep working even if a licence ends: you pay for the ability to change them. Self-hosted: on request.
FAQ
Frequently asked questions.
Short answers about data, availability, security and control.
What is server-driven UI (SDUI)?
Server-driven UI (SDUI) means the server, not the app build, decides what a screen shows. The app receives a description of the screen — widgets, layout, texts and actions — and draws it with its own components. A change reaches users when it is published, not when a new version passes store review. HotLayout is the visual editor that produces these descriptions, plus the SDKs for React, Flutter, iOS and Android that draw them.
Does our customers’ data pass through HotLayout?
No. A screen document names data paths such as user.firstName; the values travel from your own backend to your own app at the moment the screen is shown. HotLayout stores layouts, themes, media and the data dictionary, which is a description of fields. One caveat: the dictionary holds sample values that your team types in for the preview, so use made-up ones.
What happens to our app if HotLayout is unavailable?
Your app does not have to ask us for anything when it shows a screen. With the webhook, every published document is sent to your backend and served from your own infrastructure. The readers expect a bad day too: the Flutter reader draws a copy bundled with the app when the network gives nothing usable, and the React loading example keeps the screen it already has. While HotLayout is down you cannot publish a change; what is already published keeps working. The direct address, meant for prototypes and small apps, is the exception: it reads from our storage.
Can a layout run arbitrary code in our app?
No. A document is data: a closed vocabulary of widgets and named actions, checked against a JSON Schema — not a script. The reader treats the document and the theme as untrusted input: every value is checked by its form before it becomes a style or an image address. It never opens a link by itself; addresses and deep links are handed to your code, which decides what is allowed.
What happens to older versions of our app when a layout is updated?
Every document carries the version of the contract it was made for. Within one major version an older app draws a newer document: a minor version only adds optional things, and what a reader does with anything it does not know is written down in the compatibility policy. A document of another major version is not drawn at all — the Flutter reader falls back to the copy bundled with the app — so a breaking change does not reach an app that cannot read it.
How do we know a published document really comes from you?
Every webhook request is signed with HMAC-SHA256 using the secret of your project. The secret is shown once, when the webhook is turned on, and cannot be read back afterwards. Your backend checks the signature over the timestamp and the raw body before it accepts a document.
What about languages, right-to-left scripts and accessibility?
Translations and plural forms live in the document; numbers and dates follow the user’s locale, and the layout mirrors for right-to-left scripts. The web reader draws real buttons, inputs, tabs and dialogs, with keyboard support, a visible focus ring and ARIA roles, and the editor does not publish a button without an accessible name. Colour contrast depends on your theme, and alternative texts on whoever builds the screen.
Who can publish, and can we require approval?
Roles separate editing from publishing. A project can require a review: an editor sends a frozen version, another person approves it, and only then the publish button works. Every step is in the activity log.
Can we run HotLayout in our own infrastructure?
On request. The editor ships as one static file for your own admin, reads and writes through your storage API, signs in with your session and checks its licence key offline. Nothing is requested from HotLayout or Google. It comes with a licence, after a pilot, which runs in our cloud with a webhook. Write to us, and we will go through what your team needs.
How much does it cost?
A licence for one app is €4,800 per year with the editor in our cloud, or €9,600 with the editor inside your own admin — however many people use the app. We start with an 8-week paid pilot for €2,500: it includes integrating the SDK into your app together with us and is credited in full if you take a licence within 30 days. Each further app of the same company is 30% less.
Who builds it
Built by an engineer who needed it.
Before HotLayout I led a team at a Ukrainian bank. That is where it started: we needed a way to change screens without waiting for a release, so my team built an internal tool for it.
It did exactly what the bank needed at the time. I could already see how much more it could do and wanted to make it better and easier to use. Then the bank’s priorities changed, and the tool stayed as it was.
HotLayout is what I wanted it to become.
Erika DyendyeshyFounder · Flutter engineer, 6+ years
See it on your own screen.
Tell us which screen you keep releasing for. We will show how it is built in HotLayout and what the integration takes in your app.