Branded guest app
Every other app
looks the same.
Most 'branded' apps are one product with a logo dropped into it, and your guests can tell. Habitu's guest app takes your colours, your type, your splash and your menu, configured in a studio you drive yourself, published the moment you say so, opened from a link or a QR code. Set up in an afternoon.
Your colours, your type, your splash. Set them once and every screen picks them up.
Arrange the guest app in a live phone canvas that runs your real catalogue.
One action moves your draft to the app guests read. No release, no app-store queue.
Every publish is snapshotted, so undoing a change is picking a row from a list and publishing it again.
What is a branded restaurant app?
A branded restaurant app is a guest-facing app that carries one restaurant's identity (its name, colours, type and menu) rather than a marketplace's. Guests use it to order, to check their points and to read messages from the brand. The modern version is configured by the operator rather than commissioned from a software house, and it opens from a web address instead of an app store.
- App Studio
- The editor where you configure the guest app: a rail of your screens, a live phone canvas, and a properties panel. No code, no deploy.
- Draft and published
- Two copies of your configuration. You edit the draft; the app your guests open is served the published one, and only after you press Publish.
- Brand token
- A single value that every screen reads (accent, page, card surface, text, button), so one change repaints the whole app at once.
- Progressive web app
- The guest app runs in the browser at your own address. Nothing for a guest to install, and no store review between you and a change.
App Studio
Changing your app should not need a release.
Three columns: a rail of the screens your guests use, a phone canvas in the middle, a properties panel on the right. Click a section, on the rail or on the canvas, and its settings open. Everything lands in a draft, and only Publish puts it in front of anyone.
Start where your brand already is
Six configured templates and a blank canvas. Give us your website and they preview with what we can pull from it: your logo, your colours, your own photography. Then you pick one.
A canvas, not a mock-up
The phone in the middle runs your real catalogue and your real theme through the same components the live app mounts, so the preview and the app are not two different things.
Draft and live stay separate
Rework next month's look while this month's app carries on unchanged. Saves carry a lock, so a colleague's edit surfaces as a conflict instead of quietly overwriting yours.
A history you can walk back
The database snapshots each publish itself, and your own named saves sit in the same list. Going back to a recent version is a pick, not a rebuild.
DRAFT · 3 unpublished changes. Guests keep reading the published version until you press Publish.
Your identity
One accent colour is not a brand.
Habitu themes at the value level, not the screen level. Page background, card surface, text and each button variant are separate settings, written as CSS variables at the document root. Change one colour and every screen repaints, the editor canvas included, because it themes through the same function. The display face is a setting of its own alongside them.
Colour past the accent
Page, cards, text and the fill, label and stroke of each button variant all have their own value, so the app can be pale and flat or dark and layered.
Your face on the headings
Pick the display typeface and the app's headings take it, either a condensed editorial face or a lighter display one. Nothing in the guest app reads Arabic yet: the screens are English, and a full Arabic app is on the roadmap, not finished.
The first thing they see
A colour or a full-bleed image, your own logo, and how it resolves. The hero too, up to five slides, each with an image, a colour, or a muted video you host and point us at.
Never our colour
Configure no colours at all and the app falls back to a quiet neutral, not Habitu's lime. Our brand is not a default that leaks into yours while you are still deciding.
Set no accent and the app falls back to a quiet neutral, never Habitu’s colour. Low-contrast pairings raise an advisory, not a block.
Between visits
The screen they open when they are not ordering.
Ordering is a five-minute relationship. The loyalty home is the screen a member opens on a Tuesday afternoon to see where they stand. It is the reason a branded app beats a card in a wallet. It reads the same programme your dashboard configures, so there is no second place to keep in step.
Balance, and how far to go
Spendable points, what they last earned, a progress bar to the next reward, and your earn rate spelled out on the same card.
Tier state comes from the server
Where a member stands is computed in the database and never re-derived in the app. With no answer from the server the card shows nothing, rather than an invented tier.
Rewards, cheapest first
Every reward in one place, as a photo rail by default or a detailed list if you prefer, each marked ready or locked against the current balance, and priced in whatever you call your points rather than in ours.
Your messages, kept
Campaigns sent to the in-app inbox stay there, newest first, with an unread dot on the bell until the member reads them. Unlike a notification, it is still there next week.
Ordering
The menu is your catalogue, not a copy of it.
The app orders from the catalogue you already run. Categories, items, sizes and modifier groups come straight through, and availability resolves against the location the guest picked. An item that is off at one site is off in the app there and orderable at the next. Nobody retypes a menu into a second system.
Categories that follow the scroll
A sticky tab rail tracks the section a guest is reading and jumps when tapped. Four layouts to pick from, from editorial rows to a photo grid.
Sold out where it is sold out
Per-location availability disables the item in the app, and the same check runs again server-side when the guest taps pay, not only when the page first loaded.
Fourteen allergens, and diets
A filter drawer hides anything carrying a flagged allergen and narrows the menu to the dietary tags a guest picks, before anyone has to ask at the till.
They can order before they sign up
A guest builds a cart with no account at all. At pay they sign in with a code sent to their phone, and the cart transfers to them in a single atomic step.
Availability is per location and re-checked server-side when the guest taps pay. A guest can build this cart before they have an account.
Questions operators ask.
Do my guests need to download an app?
No. The guest app runs in a browser at your own address, so it opens from a link, a QR code at the counter, or the link in your social profile. There is no app store between a guest and their first order, and nothing to install before they can browse, build a cart or check their points.
Can I change the app myself, or does it go through your developers?
Yourself. The App Studio is a three-column editor: a rail of your screens, a live phone canvas, a properties panel. Every edit lands in a draft that no guest is ever served. Publishing writes a new configuration rather than a new build, so the change is there for the next guest who opens the app. No ticket, no release window.
How long does it take to launch a branded app?
Set up in an afternoon. You start from one of six configured templates (cafe bistro, fine casual, juice bar, grab-and-go, specialty coffee, artisan bakery) or from scratch, then change anything. Give us your website first and each template previews under your own logo, colours and product photography before you commit. The slower parts are your catalogue and your POS connection, not the app.
Will the app actually look like my brand, or like yours?
Yours. Page background, card surface, text colour and each button variant are separate values written at the document root, so one colour change repaints every screen. The display typeface is a setting of its own alongside them, and carries across the app's screens. If you have not chosen a colour yet the app falls back to a quiet neutral rather than our lime. Habitu's colour is never a default inside a merchant's app.
Can I run the app in Arabic?
Not yet, and we would rather say so than sell it. Where a message carries an Arabic body, in the in-app inbox and in email, it renders right-to-left beneath the English one. But the guest app's own screens read in English and no Arabic display face ships today, so a full Arabic app, right-to-left layout and all, is on the roadmap rather than finished. If Arabic decides it for your guests, say so at the demo and we will be straight with you about timing.
What happens if I publish something I regret?
Every publish is snapshotted by the database itself rather than by the editor, so no publish is skipped on the way in and your recent history is kept for you. It sits alongside your own named saves, and restoring one is picking a row from a list. It loads that version back into your draft, and you publish it when you are happy. Until you do, the draft you edit and the app your guests read stay two separate copies.
What can the app actually send a guest?
The in-app inbox and email are the live channels. A campaign lands in the inbox as a message the member can go back to, with an unread dot on the bell until they read it. Push and SMS can be composed and previewed, but dispatch on those channels is not live, and we would rather say so than let you plan a launch around them.
Does ordering work with my POS?
Ordering is live end to end on Square: catalogue, per-location availability, and card, Apple Pay and Google Pay at the checkout. The Foodics adapter is post-pilot, so a Foodics operator today gets the branded app, the loyalty home and the inbox, and runs Habitu's own loyalty engine while ordering waits on the adapter.
See it under your own brand.
Thirty minutes, with your colours and your menu in it. Not a slide deck.
Book a demo →