HospitalityOS

What it is

HospitalityOS is a browser-first platform for venues such as beach clubs, pools, restaurants, hotels, and clubs. It gives each venue a configurable public site, separates its spaces into experiences, and connects physical places to digital journeys through QR codes.

The product is designed around one operational thread: a guest discovers the right venue experience, scans the right QR, activates or joins the relevant flow, orders when enabled, and gives the venue team a clear, traceable task to fulfil.

The problem and business value

Hospitality businesses often need to coordinate brand presentation, physical locations, menus, guest access, payment state, and staff fulfilment across disconnected tools. That fragmentation makes it harder for guests to know what is available and harder for teams to know which order belongs to which place.

HospitalityOS aims to make the venue itself the organizing layer. A configurable venue site supports discovery and conversion, QR identities connect guests to the exact place or service point, and operational queues give staff a shared view of paid work. The value proposition is less guesswork for guests and a more controlled handoff for venue teams.

What it does today

• Provides a multilingual web shell in Romanian, English, French, Greek, Bulgarian, and German.
• Supports account and venue onboarding, a public venue site, configurable experiences, branding content, and a QR Center surface.
• Models separate profile QR and resource QR entrypoints, with protected lifecycle actions such as provisioning, rotation, remapping, and revocation.
• Supports short-lived guest sessions, resource holds, localized menus, modifier choices, test-mode ordering, and station-based preparation tasks.
• Gives operators and staff role-aware access to queues, shifts, stations, invitations, preparation state changes, and payment reconciliation exceptions.
• Includes a staff-oriented PWA shell, health endpoints, manual-refresh fallback, and local backup and restore checks.

The implemented product is a local, synthetic Docker-first slice. The local payment path is explicitly test-only; it is not evidence of live money movement, production fiscalization, or a hosted pilot.

Integrations and data flow

The current runtime uses Next.js route handlers and Supabase Postgres RPCs as the application boundary. Supabase Auth and Postgres Row Level Security enforce organization, venue, and role boundaries, while the database owns the important state transitions for sessions, holds, orders, payment projections, preparation tasks, and reconciliation.

The QR flow resolves only the minimum public projection needed to begin a guest journey. A scoped capability is then carried through the session and order flow. Local Docker services exercise the database and authentication boundary with synthetic data. Supabase Cloud, a hosted Next.js deployment, a production domain, and live provider accounts are not connected in this repository.

The payment design has a local synthetic adapter and reconciliation model. A future Stripe Connect integration is an operational gate requiring provider account authorization, signed webhook testing, and production verification; it should not be read as an enabled live integration.

AI or automation workflow

No AI workflow is shipped in the current product, and AI recommendations are an explicit non-goal for the current release. The automation that exists today is deterministic: atomic resource holds, idempotent order and payment commands, menu-to-station routing, staff claim and transition rules, fail-closed QR lifecycle controls, and reconciliation handling.

The system is not presented as autonomous. Staff and operators remain responsible for payment review, reconciliation decisions, venue configuration, and fulfilment actions.

Lead, email, notification, or collaboration flow

The product includes account creation and a local one-use staff invitation flow with role and venue assignment checks. Local invitation links are suitable for the synthetic development runtime; hosted email delivery, MFA, and account-recovery operations still require provider setup and production testing.

Staff queue state is the authoritative collaboration surface. Realtime updates, Web Push, escalation delivery, and other background notification paths are planned promotion work, with visible freshness state and manual refresh available as the current fallback. There is no automatic AI chat assistant or owner-replied customer chat workflow in the shipped slice.

Security/privacy boundaries

The implementation keeps tenant and venue access behind server-side authorization and Postgres RLS. QR capability values are opaque and scoped, verifier data is protected, public resolution is minimized, and sensitive capability tokens are not intended for logs or public URLs. Cookie-backed guest passes are short-lived and the local runtime includes explicit fail-closed guards for sensitive flows.

The repository uses synthetic local fixtures for development and testing. It does not claim production GDPR, fiscal, payment, recovery, or availability compliance. Live secrets, provider credentials, private customer data, and production URLs are outside this portfolio brief.

What is coming next

The next work is operational rather than cosmetic: hosted deployment, provider authorization, signed payment webhooks, jurisdiction-specific fiscal and POS validation, hosted email and MFA, Realtime and Web Push promotion, stronger recovery evidence, and physical QR tag or sticker field validation.

After those gates, the roadmap points toward multi-venue administration, localized profile editing, staff handoff and escalation, richer operational reporting, configurable group policies, and carefully scoped POS or fiscal adapters. Split payments, reservations, loyalty, native apps, and broader enterprise features remain later-stage options subject to product, legal, and pilot evidence.

Current activity or evidence from the project

Recent repository work has focused on the commercial venue surface, QR Center controls, operator hardening, browser accessibility, degraded-mode recovery, and concurrency protection. The documented local evidence covers repeatable reset and verification flows, tenant-isolation checks, the QR-to-order-to-staff journey, backup and restore rehearsal, multi-browser accessibility checks, and race protection around resource holds and task claims.

This evidence describes a working local acceptance slice with active product development around it. It does not represent production deployment, live customer adoption, revenue, or verified business outcomes.