HospitalityOS

Public project brief. The development schema and sanitized demo fixtures live in Supabase Cloud; the public web shell is deployed to production without a database connection. Live-money and hosted operational capabilities remain gated.

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 public site, separates its spaces into experiences, and connects physical places to digital journeys through QR codes. Site configuration is currently a stored foundation; the complete editor is planned.

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 public venue site supports discovery, 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 local account and venue onboarding, a public venue site, configurable experiences, and a QR Center surface. Signup creates the first venue site configuration; the full site editor is still pending.
• 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 application is moving from a local synthetic slice to hosted development. Its development schema and sanitized synthetic venue/menu fixtures are provisioned in Supabase Cloud. Production is currently a database-free public web shell. Local payment paths remain explicitly test-only; they are not evidence of live money movement, production fiscalization, or a hosted operational 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. Supabase Cloud hosts the versioned development schema and demo content. The public Next.js web shell is deployed to Production without access to that development database. Hosted guest sessions, operator signup, ordering, payments and fiscal actions remain disabled, and live provider accounts are not connected.

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 not in the current release

• The Supabase Cloud project is development-only and contains sanitized demo content. Production serves the public Next.js shell without a database connection; it has no development Auth accounts, memberships, QR verifier rows or operational data.
• No live Stripe payment flow, signed provider webhook, fiscal receipt engine, or production POS adapter is connected.
• No production email delivery, MFA, account recovery, retention/deletion workflow, Realtime/Web Push promotion, or physical QR supplier integration is included.
• Venue site content is rendered from the stored configuration foundation, but a complete operator-facing branding/content editor is not shipped yet.

What is coming next

The next work is operational and product-facing: the venue site editor, 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; the production web-shell deployment is recorded separately in E-61. It does not establish live customer adoption, revenue, or verified business outcomes.