Ostely
The hotel stay, in the guest’s hand. Without installing a thing.
Ostely replaces the paper welcome booklet and the calls to reception. The guest scans a QR code in their room, types a six-character code, or uses the in-room tablet: within seconds they are identified, bound to their room, and their stay fits in their phone. Behind it, the hotel runs everything in real time, and the platform operator manages every hotel it sells to.
- Category
- Multi-tenant SaaS platform
- Platforms
- Web · iOS · Android
Where it started
Three problems recur in every establishment: a front desk buried in low-value calls, a paper booklet that is never up to date and exists in one language only, and no data at all on what guests actually ask for. Ostely addresses all three at once — but the founding constraint is brutal: a guest staying two nights will never download an app.
So a guest had to be identified, bound to their room and allowed to order securely — with no account, no install, in seconds. And one codebase had to serve three audiences with nothing in common: the guest in the room, the hotel’s staff, and the operator selling the platform to other hotels.
What was built
The product is a web app: nothing to install, and the way in is a link. The guest is signed in anonymously, then bound to their room by a server function — the server decides which room it is, never the phone. From there everything is real-time: the order advances in front of the guest, reception sees work arrive, messaging runs both ways. Each hotel gets its own colours, logo, layouts and payment account, from the same codebase.
What the product does
Three ways in, zero install
QR code, six-character access code or in-room tablet. The guest is bound to their room in seconds, with no account to create.
Ordering with live tracking
Guests follow an order from received to delivered, without refreshing and without calling reception.
Three payment paths
Pay on delivery, pay online, or charge to the room — each switchable hotel by hotel.
Requests and messaging
Towels, housekeeping, maintenance: several requests in one, with a traceable status, plus a direct thread with reception.
Digital welcome booklet
Wifi, spa, restaurant, opening hours, local highlights: structured, illustrated, bilingual and always current.
Real-time back-office
Revenue, orders, requests and average order over the day, week, month or year — with one-tap acceptance.
Content and layout without a developer
Hotels compose their booklet and news from modules, pick their layouts, and edit their own menu.
Operator console
Create a hotel and its first admin in one action, suspend an account, and set which features each plan includes.
The decisions that mattered
Identifying a guest without asking for an account
The guest is signed in anonymously, then elevated by permissions only the server can issue: the phone presents a QR token or an access code, a server function validates it and binds the session to one specific room. The guest never asserts where they are. That is what makes “no install, no signup” compatible with real security — and it is also what lets the hotel cut access the moment a room is reset at checkout, so a departed guest can no longer order to that room.
Surviving a browser refresh
On the web a guest can reload at any moment, and being logged out would be fatal to the experience. The session is therefore restored locally before the first frame, while a live watch listens for a genuine revocation. The hard part is telling a real revocation apart from a cached echo: the two look alike, and confusing them signs out a legitimate guest mid-order.
A multi-tenant product that doesn’t look multi-tenant
Each hotel is partitioned by its path in the database, and its identity — colours, logo, theme — is applied at runtime. The four main surfaces (categories, products, home, booklet) are composed from preset layouts the hotel chooses. The result: the same code produces visibly different applications, without duplicating a line.
Content the hotelier actually owns
Rather than hardcoding what a welcome booklet is, staff define their own modules — typed field templates — and fill them in. That is the difference between a product a hotelier can shape and one that needs a developer for every content change. The same mechanism powers both the booklet and the news.
Money in the right account
Payments run through Stripe Connect: funds land in the hotel’s account, not the platform’s, which takes its fee along the way. It is the only arrangement that avoids the operator becoming a payment institution itself. Payment confirmation is never taken on trust from the client: it is verified through a signed notification received directly from Stripe.
How it fits together
Flutter Web
One codebase, three interfaces: guest, hotel, operator
Cloud Firestore
Real-time, partitioned per hotel: orders, requests, messaging
Cloud Functions
What the client must not decide: room sessions, payments, emails
Stripe Connect
Money lands in the hotel’s account, the platform takes its fee
The technologies used
Frontend
- Flutter
- Dart
- Cubit
- Freezed
- go_router
Backend
- Cloud Functions
- TypeScript
- Node 22
Infrastructure
- Firebase
- Cloud Firestore
- GitLab CI
Services
- Stripe Connect
- Firebase Cloud Messaging
- Sentry
What was delivered
Platform delivered solo, from product to production: guest web app, hotel back-office, operator console, twenty server functions, Stripe Connect payments, push notifications and automated deployment. Twenty-five features, roughly 61,000 lines of Dart, two languages. Operating results will be added once confirmed with the client.
- Web
- iOS
- Android
Need a similar product?
Let’s talk about what you want to build. I reply personally, usually within 24 hours.