Theatre Walk-in — Case Study

Theatre Walk-in — Visitor Management & Gate Security Platform

A single progressive web application that runs reception kiosks, a parking-gate security check, and an operations dashboard for a major theatre company's multi-building campus.

Industry

Arts & culture / performing-arts venue operations

Product type

Multi-surface progressive web application (PWA) — kiosk, mobile gate app, admin dashboard

Built by

Monthos

Live URL

Withheld for security reasons (production deployment)

At a glance

The problem / What we built

Reception sign-in, on-site visibility, and vehicle access were fragmented and hard to audit. We built one cloud-hosted PWA that handles visitor sign-in/out, a live register and emergency roll call, staff onboarding, and ID + VIN verification at the parking gate.

Who it's for

Reception and operations staff, security guards on the gate, administrators, and the visitors and staff who pass through the venue each day.

Stack

React 19, React Router 7, Tailwind CSS 4, Vite 6, vite-plugin-pwa; Supabase (PostgreSQL, Auth, Storage, Realtime) with Row-Level Security and SECURITY DEFINER RPCs.

Scope / Deployment

One installable PWA across three surfaces — iPad kiosks, guard phones, and admin browsers — backed entirely by managed cloud services, with no on-premises infrastructure.

Project impact

Monthos built one progressive web app that runs reception kiosks, a parking-gate security check and a live operations dashboard for a multi-building venue—no on-site servers.

Always know who's on site. A real-time register and one-tap emergency roll call replace paper and ad-hoc sign-in sheets.

Defensible vehicle access. Two-step SA ID + VIN verification at the gate, validated server-side, with a full allow/deny audit log.

Faster for the people using it. Cellphone-first sign-in recognises returning visitors and staff across a six-language kiosk interface.

Secure by construction. The public kiosk physically can't read the register—sensitive data is reachable only through narrow server-side procedures, with admin rights enforced in the database.

Who this is for: venues, campuses and multi-building sites that need visitor management and gate security—reception and operations staff, security guards and administrators.The challengeA working venue with several buildings needs to know — reliably and in real time — who is on site and who is allowed to drive in. The day-to-day pain points the platform addresses:

No single source of truth for who is on site. Paper or ad-hoc sign-in makes it slow to answer "who is in the building right now?" — exactly the question that matters most in an emergency.

Multiple reception points, no attribution. With several buildings and entrances, there was no clean way to record which location and device a visitor signed in at.

Slow, repetitive sign-in. Returning visitors and staff were re-entering the same details every visit.

Unverified vehicle access. The parking gate needed a fast, defensible way to confirm a driver is a genuine staff member with a registered vehicle — not a manual list check.

A diverse, multilingual public. A single-language interface excludes a large part of the visiting public.

Privacy and accountability. Visitor photos, contact details, and South African ID numbers are sensitive; the system must limit who can see what and keep an audit trail — without putting privileged credentials on a public kiosk.

Existing hardware, no servers. The solution had to run on devices the venue already owns and avoid any on-premises servers to maintain.

Our approachMonthos designed the system as one application with three purpose-built surfaces rather than three separate products. A kiosk shell, a gate shell, and an authenticated admin area share the same codebase, data model, and security rules, which keeps the build coherent and the operational footprint small.Guiding principles:

Cloud-only, hardware-light. Everything persists in managed cloud services so the venue runs the app on its existing iPads and phones, with nothing to host on-site.

Security at the data layer, not just the UI. The public kiosk uses an anonymous key and can only reach the database through narrow, server-side procedures. It cannot read the full register.

Fast paths for repeat users. Sign-in starts from a cellphone lookup so returning visitors and staff are recognised and pre-filled instead of re-typing.

Designed for the floor, not the desk. Large touch targets, light/dark themes, a multilingual interface, and short auto-returning flows suit unattended kiosks and a busy gate.

Locale-correct by design. South African ID, VIN, vehicle, and phone-number handling are first-class, validated server-side.

Installable and resilient. A service worker and PWA packaging let each surface pin to a device home screen and run full-screen like a native app.

What we deliveredVisitor kiosk (public, no login)

Touch-optimised Sign In and Sign Out home screen, with a hidden settings entry to the admin area.

Six-language interface — English, Afrikaans, Sesotho, isiZulu, isiXhosa, and Setswana — plus a light/dark theme toggle.

Cellphone-first sign-in that branches automatically: recognised staff get a fast path, returning visitors get pre-filled details, and first-time visitors get a guided flow.

Visitor categories for first-timers: Student, Visitor, Contractor, Performer / Artist, and Delivery.

Photo capture via the device's front camera, with retake and a graceful fallback when no camera is available.

Host selection with type-ahead search and highlighted matches, plus a free-text host fallback when the host isn't in the directory.

Confirmation and success screens with a personalised greeting, an optional spoken welcome, and an auto-return countdown.

Sign-out by cellphone that finds active visits (up to five), shows time on site, and confirms departure — secured so an anonymous kiosk user can only act on their own visit.

Operations & emergency

Live register of everyone currently on site, with a per-second duration counter, location/device attribution, and real-time updates via Supabase Realtime.

Manual sign-out and CSV export of the current on-site list.

Emergency roll call — a high-visibility, print-friendly headcount view of everyone still inside.

Visit history with date-range filtering, plus per-visitor profiles aggregating visit counts and total time on site.

Parking gate (guard phone)

A separate gate shell running on a registered guard phone at the parking gate.

Two-step staff vehicle verification: scan a South African ID barcode (PDF417 / QR) or enter the 13-digit ID manually, then enter the 17-character VIN.

Server-side validation — SA ID format and Luhn checksum, normalised VIN — with a clear allow (staff name + licence plate) or deny (specific reason code) result.

Full audit trail: every attempt, allowed or denied, is logged.

Staff onboarding & administration

Public staff self-registration via a shareable link — a three-tab form (photo, personal details with SA ID, and vehicle) that lands in an unverified state pending admin approval.

Staff management: search and filter by verification/active status, full CRUD, vehicle records (plate, VIN, make/model from an SA catalogue, colour), and bulk CSV import for onboarding.

Device fleet management (admin-only): register, edit, deactivate, and remove kiosks and gate phones; see online status, last-seen, visit counts, and per-device session timeout.

Gate audit log (admin-only): a reviewable history of recent gate scans with outcomes and reasons.

Surfaces and roles

Surface

Who uses it

Access model

Kiosk (/, /signin/*, /signout/*)

Visitors & staff

Public, anonymous; device registered to a location

Gate (/gate/*)

Security guards

Device registered as a gate phone

Staff registration (/staff/register)

Staff (self-service)

Public link, no device setup

Admin dashboard (/admin/*)

Reception / operations

Supabase Auth (email/password)

Admin-restricted (devices, gate log)

Administrators

Authenticated and is_admin on staff record

Technical highlights

Layer

Technology

React 19, React Router 7, Tailwind CSS 4, shadcn-style components, Motion

Build & packaging

Vite 6, vite-plugin-pwa, service worker, installable PWA

Backend

Supabase — PostgreSQL, Auth, Storage, Realtime

Database access

SECURITY DEFINER RPCs over Row-Level-Security-protected tables

Media

react-webcam capture → Supabase Storage buckets

Barcode

html5-qrcode (PDF417 + QR) for SA ID scanning

Utilities

date-fns (durations), Sonner (toasts), next-themes (theming)

Architecture decisions worth highlighting

One app, three shells. KioskShell, GateShell, and the authenticated admin area share a single React app, data model, and security model — reducing duplication and operational overhead.

Defence at the data layer. Tables have Row-Level Security enabled. The public kiosk holds only an anonymous key and reaches sensitive data exclusively through narrow, fixed-search_path SECURITY DEFINER procedures (e.g. find_visitor_profile, find_active_visit, sign_out_visit, verify_and_log_gate_entry). It cannot enumerate the register.

Role gating in the database. Administrator-only capabilities are enforced server-side via current_user_is_admin(), which links a Supabase Auth user to an active staff record flagged is_admin — not merely hidden in the UI.

Device identity & attribution. Each kiosk/gate registers with a persistent device key and sends a heartbeat (last-seen, app/OS version); every sign-in records the originating device_id so admins can see which kiosk and building area was used, and online status is derived from recency.

Locale-correct validation, server-side. SA ID validation (structure, birth-date, and Luhn checksum), VIN normalisation, licence-plate and phone-number normalisation are implemented as database functions, so the rules can't be bypassed from the client.

Real-time operations. The visits table is published to Supabase Realtime, driving the live register and emergency headcount without polling.

Demo/mock mode. The app degrades to a mock mode when Supabase isn't configured, which keeps local development and demos friction-free.

┌─────────────────────────────────────────────┐ │ Theatre Walk-in (PWA) │ │ │ iPad kiosks ──┤ KioskShell GateShell Admin (/admin) ├── Admin browsers Guard phone ──┤ sign in/out ID + VIN live register │ │ multilingual verification roll call │ └───────────────┬──────────────────────────────┘ │ HTTPS only anon key │ narrow RPCs │ Supabase Auth (admin) ▼ ┌─────────────────────────────────────────────┐ │ Supabase │ │ Postgres + RLS · SECURITY DEFINER RPCs │ │ Auth · Storage (photos) · Realtime (visits) │ └─────────────────────────────────────────────┘OutcomesThe platform replaces fragmented, manual processes with one auditable system. Mapped to the capabilities actually built:

Before

After

No reliable real-time view of who is on site

Live register with per-second durations and a one-tap emergency roll call

Sign-ins not attributable to an entrance

Every visit records its kiosk, location, and device

Repeat visitors re-enter details each time

Cellphone lookup recognises and pre-fills returning visitors and staff

Manual, hard-to-audit vehicle access

Two-step SA ID + VIN verification with a full allow/deny audit log

Single-language interface

Six-language kiosk experience

On-premises hardware to maintain

Fully cloud-hosted; runs on existing iPads and phones

By the numbers (from the codebase)

Metric

Value

Database migrations

Core data entities

6 (staff, visits, locations, devices, staff vehicles, gate entry logs)

Database functions / RPCs

~17 distinct SECURITY DEFINER procedures

Application surfaces

3 (kiosk, gate, admin)

Distinct user roles / access tiers

Kiosk interface languages

First-time visitor categories

Admin dashboard sections

Why this project mattersTheatre Walk-in is a strong reference build because it shows Monthos delivering a single, coherent product that serves very different users — an unattended public kiosk, a guard at a gate, and an operations administrator — without splitting into multiple apps or compromising on security.It demonstrates security designed at the data layer: a public surface that physically cannot over-reach, role checks enforced in the database, and sensitive logic that can't be bypassed from the client. It also shows local-context engineering done properly — South African ID, VIN, vehicle, and phone handling are first-class — and a cloud-only, hardware-light deployment that fits an organisation's existing devices. The result is the kind of production-grade, operationally pragmatic system Monthos builds for venues and enterprises.Services demonstrated

Product design across multiple user surfaces (kiosk, mobile, dashboard)

Progressive web app engineering (installable, offline-aware, service worker)

Cloud backend design on Supabase (PostgreSQL, Auth, Storage, Realtime)

Security & privacy engineering — Row-Level Security, SECURITY DEFINER RPCs, role gating, audit logging

Real-time data and live operational dashboards

Locale-specific validation (South African ID, VIN, vehicle, phone)

Multilingual, accessibility-conscious UI

Device fleet provisioning, heartbeat, and management

Data tooling — CSV import/export and self-service onboarding workflows

Get in touchMonthos designs and ships custom, production-grade applications — from public-facing kiosks to secure operational platforms. If you have a similar problem, we'd like to hear about it.monthos.comCase study prepared for Monthos.com · Project: Theatre Walk-inMonthos Group — Cheltondale, Johannesburg, SA. Email info@monthos.com, phone +27 (68) 750 7313.Case studies · Privacy Policy · Terms of Service