Super Meeting: Connecting Meeting Operations to the Room Door

Super Meeting is a two-part meeting-room operations system. The main application gives staff one place to manage locations, rooms, bookings, visitors, payments, access permissions, and operational reporting. A companion progressive web app turns wall-mounted tablets into room-specific displays that communicate availability and the day's schedule where people need that information.

We built the applications as separate Next.js products with a deliberate boundary between them. The administration platform owns operational data and privileged workflows. The display application consumes a narrow, read-only view of that data through its own server-side proxy. This separation keeps the public-facing display simple and resilient without exposing administrative credentials or capabilities in the browser.

The result is not just a booking interface. It is an operational chain that connects a reservation to payment, customer verification, physical access, staff oversight, and the display outside or inside the selected room.

The challenge

Meeting-room operations cross several systems and audiences. Staff need to configure inventory, resolve schedule conflicts, take payment, manage visitors, and understand how rooms are being used. Guests need clear confirmation and valid access credentials. People standing at a room need an immediate, trustworthy answer to a simpler question: is this room available?

Treating each concern as an isolated screen would leave the difficult problems between them:

• A booking must reserve the correct room across every selected date and time slot.
• The amount shown to a customer must match the amount calculated and charged on the server.
• A successful reservation may need to create a payment session, issue a receipt, notify the guest, and provision time-bound door access.
• Permissions must apply consistently across navigation, pages, API routes, and sensitive support workflows.
• A wall display must remain useful during unreliable connectivity without quietly presenting stale information as current.
• English and Arabic interfaces must work across desktop administration and landscape kiosk displays.

We approached Super Meeting as one domain with two purpose-built surfaces: a rich operational control plane and a constrained room-side display.

The solution

An operations platform for staff

The Super Meeting administration application centralizes the workflows required to operate a portfolio of meeting spaces. Staff can manage branches, room categories, rooms, amenities, and room pricing; create and update bookings; administer promo codes; track visitors; manage users and roles; and review dashboard information and device audit events.

The booking flow carries more responsibility than a conventional calendar form. It supports multiple selected dates and time slots, checks availability, calculates pricing, applies eligible coupons, records the operator responsible for a booking, and routes the transaction according to the selected payment method. MyFatoorah integration supports hosted card-payment and invoice flows, while success and failure routes give the customer a clear return path. Tokenized receipt pages allow a receipt to be retrieved without exposing an unrestricted booking record.

Verification and communication are part of the same workflow. The application includes email verification and an optional phone-verification path backed by Kalaam SMS. Once a booking is ready, branded confirmation email can provide the guest with the booking details and credentials they need.

The dashboard turns booking data into an operational view: total bookings, recent activity, revenue, and room utilization are derived from the same source used by the booking workflows. This keeps reporting close to the underlying operational model instead of creating a separate analytics silo.

A focused experience at each room

The Super Meeting PWA is designed for fixed, wall-mounted tablets. During provisioning, an installer assigns a device to a branch, a room, and one of two display modes:

• Outside communicates room availability to people in the hallway.
• Inside emphasizes the active meeting, the remaining time, and an approaching wrap-up window for occupants.

The assignment is persisted on the device together with cached room and branch labels. On a later boot, the display can render its identity immediately and refresh it in the background. It does not force the tablet back into setup simply because the network is unavailable.

Provisioned settings are protected by a PIN, while URL-based provisioning parameters provide a faster commissioning path for a device fleet. The production display itself is read-only: booking and schedule changes remain in the operational application, outside the reach of passers-by.

Technical architecture

Both applications use Next.js 16, React 19, TypeScript, Tailwind CSS, shadcn/ui primitives, and next-intl. The administration application adds Supabase, TanStack Query, Zod, React Hook Form, and Recharts to support its data, validation, form, and reporting requirements.

Staff browser
    |
    v
Super Meeting admin + API routes
    |             |              |
    v             v              v
Supabase      MyFatoorah     Kalaam / email
bookings,     payments       verification and
rooms, users                 notifications
    |
    +---------------------> CVSecurity
    |                       time-bound access
    |
    v
Scoped booking API
    ^
    | server-to-server request with optional enforced API key
    |
Super Meeting PWA route handlers
    ^
    | same-origin, read-only schedule requests
    |
Room tablet + service-worker cache

A narrow boundary for room displays

The tablet browser never calls the administrative backend directly. Browser requests go to same-origin PWA route handlers, which use a server-only client to contact the Super Meeting API. When API-key enforcement is configured, the credential is attached only on that server-to-server hop and does not enter the client bundle.

The schedule endpoint accepts a room, the device's local calendar date, and a bounded number of days. It requests only the relevant bookings and then re-checks every returned row against the requested room and date before sending it to the display. This defensive filtering protects room privacy even if an older or misconfigured upstream service ignores query parameters. Cancelled bookings are omitted, malformed rows are skipped, and partial multi-day results can still be returned when at least one requested day succeeds.

This boundary is deliberately narrower than the administration API. The display receives the schedule fields it needs, not a general-purpose view of customers, payments, or access credentials.

Supabase as the operational data layer

Supabase provides authentication and the Postgres data layer for branches, rooms, amenities, bookings, coupons, verification sessions, visitors, users, roles, and impersonation records. Database migrations enable row-level security on exposed operational tables, while the application adds permission checks around administrative requests.

Client-side data access is organized with TanStack Query, but privileged or multi-system workflows stay in server routes. This is particularly important for booking creation: pricing, coupon rules, payment initiation, access provisioning, and outbound communication cannot be trusted to browser-calculated state.

Preventing conflicting reservations

Availability is enforced at more than one layer. The server performs a human-friendly conflict lookup so it can explain which reservation occupies the requested period. Postgres provides the final concurrency-safe guarantee through booking overlap enforcement in the database.

This matters because two valid browser sessions can pass a preflight check at nearly the same time. The database remains the authority that prevents both writes from claiming the same room and slot. Multi-date bookings preserve the selected dates as first-class data, and indexed date arrays support room-and-day schedule queries without reducing a range booking to ambiguous display text.

Server-owned pricing and payment state

Room pricing and coupon evaluation are performed on the server for callers that cannot be trusted to supply their own total. Coupon rules cover activation windows, usage limits, minimum amounts, fixed or percentage discounts, maximum discounts, and room-category applicability. Monetary values are rounded to whole halalas and discounts are bounded so they cannot reduce a charge below zero.

MyFatoorah callbacks are verified against payment status before a booking is marked paid. Callback updates are designed to be repeatable: only the request that transitions a booking into the paid state receives the data used for follow-up credential email. A downstream email outage does not reverse a payment that has already been confirmed.

That separation is intentional. Payment truth belongs to the payment provider and booking record; notification delivery is a related side effect, not the authority on whether money was received.

Connecting reservations to physical access

The CVSecurity integration turns booking credentials into time-bound physical access. For a new guest, the application reserves a PIN, creates the person with an access window and configured access levels, and then sets the separate device password required by the terminal. The access interval can include a configurable grace period for early arrival and departure.

The integration also accounts for failure between the two CVSecurity calls. If the person record is created but the device password cannot be set, the application attempts to remove the partial record rather than leave behind a guest who appears enrolled but cannot authenticate at the door. Access can also be revoked when the associated booking is removed.

These choices make the physical-access workflow observable and recoverable without making a temporary access-control outage the sole authority over whether a booking can be recorded.

Permission-aware administration

The authorization model expresses permissions as explicit module/action pairs for branches, rooms, amenities, bookings, coupons, devices, doors, customers, payments, verification, users, and roles. The same vocabulary can be used to filter available navigation and actions and to guard server requests.

User impersonation is treated as an auditable support workflow rather than an invisible account switch. Server-owned records capture the impersonator, target user, timestamps, status, and reason without storing authentication tokens. Permission-aware routing limits the destination available to the impersonated session, and the interface makes the temporary state visible.

Engineering for an unattended PWA

An unattended room display has different failure modes from a typical responsive website. It may reboot without a network connection, remain open for months, or receive an application update while someone is reading it. We designed the PWA around those conditions.

Offline without false confidence

The service worker precaches the application shell, offline route, icons, and core brand assets. Schedule requests use a network-first strategy: fresh data always wins, but the last successful room schedule can be replayed when the network fails. Cached schedule responses are rebuilt with explicit cache-status and cache-timestamp headers.

The UI reads those headers and displays an offline or stale-data indicator with the time of the cached response. This distinction is essential. An old schedule can still help someone orient themselves, but it should never masquerade as a live answer.

Cache versions are explicit, old application caches are removed during activation, and cache sizes are bounded for long-running devices. If neither the live application nor a cached shell is available, the dedicated offline page gives the user a retry path instead of a browser-generated failure screen.

Controlled updates

The service worker registers only in production; development actively removes registrations so stale assets do not distort local testing. In production, the application checks for updates periodically but avoids reloading immediately under a user's hand. A newly activated worker triggers a reload when the display is hidden or after an idle interval, with interaction restarting that countdown.

This balances fleet freshness with predictable kiosk behavior. The display can adopt a new build without interrupting an active interaction at an arbitrary moment.

Kiosk-specific interface decisions

The web app manifest requests fullscreen landscape presentation and includes standard, maskable, and Apple touch icons. The viewport prevents accidental pinch zoom, fills safe-area space, and avoids browser auto-linking of room numbers or meeting times. Touch targets in setup are sized for fingers rather than pointer precision.

English and Arabic share the same component system. Locale selection changes document direction, translations, date formatting, and the primary typeface. The display mode changes its language as well as its layout: the same room state is explained differently to a passer-by outside and an occupant inside.

Key engineering decisions

Several principles shaped the implementation:

1. Keep authority in the right layer. Postgres owns the final overlap guarantee, the server owns price calculation, and MyFatoorah owns payment truth.
2. Limit the public display's capabilities. The PWA consumes a room-scoped projection through server-side routes and exposes no production booking controls.
3. Design degraded states as product states. Partial schedules, cached responses, failed notifications, and interrupted access provisioning are handled explicitly instead of being collapsed into a generic error.
4. Boot from local identity, refresh in the background. A temporary registry outage does not make a correctly provisioned tablet forget which room it serves.
5. Treat bilingual support as structural. Direction, typography, dates, and context-specific copy are part of the shared architecture rather than a late translation pass.
6. Make privileged support visible and traceable. Fine-grained permissions and audited impersonation reduce the need for broad, opaque administrative access.

Outcomes

The repositories do not contain verified adoption, time-saving, or revenue metrics, so we do not attach invented numbers to the project. The implemented system nevertheless demonstrates several concrete operational improvements:

• Staff can operate rooms, bookings, visitors, pricing, payments, and access from a shared data model.
• Schedule conflicts are guarded both before and during the database write.
• Room displays present a consistent projection of the booking system while remaining isolated from privileged workflows.
• Guests can move from verification and payment to receipt, confirmation, and time-bound door access within one coordinated booking process.
• Operators receive dashboard visibility into booking activity, revenue, and utilization.
• Wall tablets remain informative through network interruptions and clearly disclose when their schedule is not live.
• A single bilingual display build can be provisioned for different rooms and inside/outside contexts without room-specific deployments.

These are architectural outcomes rather than measured business claims. They show how the system reduces gaps between digital reservations, staff operations, and the physical meeting-room experience.

Reflection

Super Meeting's defining challenge was not rendering a calendar or a room-status screen. It was deciding where each piece of truth belongs and preserving that truth across administrative actions, external services, and unreliable room-side devices.

Separating the operational platform from the display PWA gave each surface a clearer security and reliability model. The administration application can coordinate complex workflows; the display can remain narrow, readable, and resilient. Between them, guarded APIs and a shared booking model carry the minimum information required to connect office operations to the room door.

Technology summary