Sports Bar Application

Executive summary This plan covers the Victory & Vice companion app — a premium in-venue experience layer for the West Loop sports-and-nightlife venue. The two signature features (TV audio to personal headphones via AudioFetch, and the custom screen / section “request your game” reservation) are the reason a guest downloads the app, and they anchor the launch. The remaining work is largely integration: the app reads from and writes to the venue’s existing systems of record rather than creating a parallel guest database. The plan is organised in two phases. Phase 1 is the launch companion app, compressed to ~10 weeks to deliver all launch features for a late-summer 2026 opening; Phase 2 is the post-launch front-door commerce and expanded engagement layer (~10 weeks), built on the same stack without a rebuild. It is delivered as a Turborepo monorepo: a React Native (Expo) app, a Next.js (Vercel) admin, and a NestJS API on Google Cloud Run over a Supabase Postgres database. Hitting late summer means the Phase 1 workstreams run in parallel across a team of roughly two to three (mobile, native, backend, web), with continuous QA rather than a long hardening tail. The remaining risk is not engineering throughput but external dependencies — API access lead times, AudioFetch on-hardware testing, carrier vetting for SMS, and app-store review. These form the critical path and must be initiated on Day 1; if a high-risk access item slips, the deferral options in Section 5 protect the date. 2. Development roadmap The roadmap shows both phases. Phase 1 (gold) is the launch build, compressed to ~10 weeks with parallel workstreams so all launch features land in late summer; Phase 2 (steel) is the post-launch commerce and engagement layer that follows. UI/UX design is embedded within each build workstream rather than run as a separate phase, with the design system set up during foundations. The access lead-time band at the top is the Phase 1 critical path and must clear early — it runs in parallel from Week 1. Page 2 VICTORY & VICE Mobile App Development Plan Figure 1 — Phased roadmap: Phase 1 launch (~10 weeks, late summer) and Phase 2 post-launch (~10 weeks). 3. Architecture & approach Built as a Turborepo monorepo, the system is a React Native app (Expo), a Next.js admin (Vercel) and a NestJS API (Google Cloud Run) over a Supabase Postgres database, sharing typed packages. The NestJS API is the single gateway that orchestrates every integration and enforces the governing principle from the brief: a single source of truth for the guest. Guest identity lives in SevenRooms; loyalty is derived from real Toast spend and visits; the app and its database own only app-native data (the screen grid, game requests, prediction pools, votes, and waitlist state). This avoids a second customer-data silo that would fail to reconcile with the venue’s POS and CRM. The screen grid is the app’s system of record for assignments, not a live control channel to the physical displays — EverPass has no public API, so pushing a confirmed assignment onto the actual screen remains a manual step performed by staff in EverPass Manager. Page 3 VICTORY & VICE Mobile App Development Plan Figure 2 — System architecture and integration map. Buy vs. build • Buy: TV audio (AudioFetch hardware + SDK) and the sports schedule / scores (licensed data API). • Build: the screen / section reservation engine — the genuine differentiator, with no off-the-shelf equivalent. Scope note: this engine assigns and tracks requests; it does not control EverPass, which has no public API — see Section 4 (Additional recommendations) for the manual execution step this requires. • Reuse: reservations, ordering, and payment stay on the venue’s existing stack (Toast / SevenRooms); the app integrates rather than rebuilds. Page 4 VICTORY & VICE Mobile App Development Plan 4. Technical stack & platforms Stack overview Layer Technology Role Mobile app React Native (Expo) iOS & Android guest client Web admin Next.js (Vercel) Admin dashboard Backend API NestJS (Google Cloud Run) Business logic, integration orchestration, auth gateway Database Supabase (Postgres) Data, auth, storage, realtime Monorepo Turborepo (GitHub) Shared types & packages across app / web / API; unified build & CI Push Firebase Cloud Messaging or OneSignal Notifications Purchases RevenueCat In-app subscriptions & purchases Distribution App Store Connect + Google Play Store publishing Platforms & tooling Platform Role Cost (indicative) Lead-time Expo (EAS) Mobile build, OTA updates, deployment Free–$ per tier Low Vercel Web hosting & deployment Free–Pro ~$20/mo Low Google Cloud Run Backend hosting (NestJS) Usage-based Low GitHub Source control + CI (Actions) Free–$ org Low Supabase Database, auth, storage, realtime ~$25/mo + usage Low Firebase / OneSignal Push notifications Free tier Low RevenueCat Subscriptions & IAP Free under threshold, then % Low–Med External integrations & store accounts These external services gate the schedule. The three flagged HIGH — SevenRooms provisioning, Twilio A2P 10DLC carrier vetting, and Apple organization enrollment — have calendar-bound waiting periods and must be initiated in Week 1. Service Purpose Owner / how to obtain Cost Lead-time risk Apple Developer (Org) App Store, push (APNs), Sign in with Apple Machine Hospitality Group — needs D-U-N-S $99/yr HIGH — 1–3 wks Google Play Developer Play Store publishing Client org $25 once Low AudioFetch SDK + hardware TV audio to guest headphones Client buys hardware; request SDK kit Hardware quote Medium Page 5 VICTORY & VICE Mobile App Development Plan Service Purpose Owner / how to obtain Cost Lead-time risk Toast API P1: read visits + spend (loyalty). P2: order & pay (write) Venue Toast acct (RMS Essentials+); read = Standard API, write = partner / mgmt-group Tied to subscription Med (P1) / High (P2) SevenRooms API Guest identity + reservations Partnerships form; rep issues client ID/secret/venue/group ID Per agreement HIGH Sports Data API Schedules, live scores, prediction resolution Dev integrates; client licenses Trial free; prod $500– 1k+/mo Medium Twilio + A2P 10DLC SMS, unify with venue identity Reconcile with venue Twilio Usage + 10DLC fees HIGH — vetting Future platforms • Mixpanel — product / event analytics to learn which features resonate and where bugs cluster, once the app has live traffic. • AppsFlyer — user-attribution tracking for marketing once paid acquisition begins. Additional recommendations • Purchase routing: use RevenueCat for digital subscriptions / membership tiers and digital perks; route physical goods (food, drink, cover charges, event tickets) through Toast’s payment rails, not App Store IAP. Apple permits external payment for real-world goods and services, which avoids the ~30% store commission on the Phase 1 marquee cover/ticket and all Phase 2 order-and-pay. • Push provider: because the brief wants behaviour-based prompts and segmented messaging, OneSignal’s built-in segmentation and journeys reduce admin-dashboard build effort versus raw FCM — worth choosing unless FCM-only control is required. • Monitoring from day one: Sentry across the app and the NestJS API (not a future item) for fast triage during the peak-crowd launch. • Secrets: store integration credentials (Toast / SevenRooms / sports / Twilio) in Google Secret Manager — already on GCP — never in the client or the repo. • Feature flags: a remote-config service (e.g. ConfigCat or Firebase Remote Config) to gate Phase 2 features and toggle any deferred Phase 1 items without resubmitting to the stores. • Single identity: Supabase Auth issues the JWT, the NestJS gateway validates it, and it reconciles to the SevenRooms client_id — keep one identity rather than splitting auth between Supabase and NestJS. • Testing: Detox or Maestro for React Native end-to-end (AudioFetch + reservation flows) and Playwright for the admin, wired into GitHub Actions. • EverPass execution gap: the screen grid is the app’s system of record for assignments, but EverPass has no public API for automated control — staff must manually action each confirmed assignment inside EverPass Manager to actually change the physical screen. Recommend a visible/audible alert at the AV station when a new assignment lands, and a full rehearsal of the assign → EverPass-execute handoff Page 6 VICTORY & VICE Mobile App Development Plan before launch under simulated game-day crowd conditions, so latency or missed hand-offs are caught before they cost a guest their requested game. Page 7 VICTORY & VICE Mobile App Development Plan 5. Phase 1 — Launch build (~10 weeks) Phase 1 delivers the full launch feature set — the complete in-venue experience layer — in time for the late- summer 2026 opening. To fit that window the workstreams run in parallel (overlapping week ranges below) rather than sequentially, which assumes a team of roughly two to three across mobile, native, backend, web and design, with QA running continuously. Payments can be made on a weekly basis. Week Workstream Key deliverables W1–2 Foundations, architecture & design system Fire ALL access requests on Day 1 (SevenRooms, Toast, sports API, AudioFetch HW, Twilio 10DLC, Apple Org). Stand up the Turborepo monorepo (app / web / API / shared) on GitHub with CI; provision Supabase; scaffold the NestJS service on Cloud Run, the Expo app and the Next.js admin; draft schema + RLS. Establish the design system (brand tokens, typography, shared components) from the brand guide. Floor-plan / screen-inventory workshop → screen-grid model. Lock the identity model (Supabase Auth → NestJS gateway → SevenRooms client_id) and the loyalty-derivation design. W2–3 Core shell · identity · push Auth (Apple / Google / social), profile, push infrastructure (Firebase / OneSignal). Begin SevenRooms identity sync the moment credentials arrive. W2–5 Signature #1 — AudioFetch Audio UI designed and built alongside the native iOS + Android bridge, started in W2 (the binding constraint); on-hardware testing through W5: discovery over wifi, headphone / Bluetooth routing, Android foreground service + permissions, wifi-drop edge cases. W3–7 Signature #2 — Screen reservation Reservation UX designed and built together with the screen-grid + viewing-zone + table→TV model (NestJS + Supabase); guest “request your game” flow; admin request inbox with screen assignment and live (Realtime) grid updates. Staff execution of confirmed assignments into EverPass Manager remains a manual step — no EverPass API exists to push this automatically. W3–7 Data integrations (parallel) Auto-populated schedule + live scores (NestJS jobs on Cloud Run); Toast read → Victory Lap loyalty engine; virtual waitlist coordinated with SevenRooms; Twilio unification (gated by 10DLC). Validate clients against each sandbox (note Toast sandbox 9 a.m.–6 p.m. ET). W5–9 Engagement features Prediction games / pools with automatic resolution and leaderboards; vote-for-the-wall (timeboxed, live tally, admin override); marquee event RSVP / ticketing. W3–8 Admin dashboard (parallel) Next.js on Vercel: screen grid, request assignment, schedule editing, prediction / prize configuration, vote control, waitlist + RSVP management, segmented messaging, loyalty / engagement reporting. Surfaces new/pending screen assignments prominently so AV staff can action them promptly in EverPass Manager. W8–9 Hardening & QA QA runs continuously throughout; final peak-crowd load testing, security / RLS review, full regression, privacy + geofence flows, store- submission prep. W9–10 Store review & launch Submit to both stores; on-site production AudioFetch validation; launch with hotfix buffer; begin support / warranty window. Schedule protection: the late-summer date depends on the Day-1 access items clearing quickly. If a high-risk item (SevenRooms, Twilio 10DLC, Apple Org) slips, the cleanest features to defer as immediate fast-follows Page 8 VICTORY & VICE Mobile App Development Plan are prediction games / pools, vote-for-the-wall, and marquee ticketing — the two signature features, schedule / scores, loyalty, and push remain the protected launch core. 6. Phase 2 — Post-launch (~10 weeks) Phase 2 is the front-door commerce and expanded engagement layer, beginning immediately after the Phase 1 launch (around Week 11). The v1 architecture (NestJS API gateway, with app-native data cleanly separated from the systems of record) is built so these features add without a rebuild. Week Focus Key deliverables W11–12 Phase 2 foundations Upgrade Toast access to write / management-group + payments; extend the data model for orders and reservations; configure RevenueCat and store products. Built on the v1 architecture — no rebuild. W11–16 Mobile order & pay (Toast) In-app menu, cart, order submission and payment; reconciliation with POS / KDS. Physical goods routed through Toast’s payment rails (not App Store IAP). W13–18 Reservations & bottle service In-app reservations (SevenRooms write) and bottle-service pre-order via the SevenRooms / TripleSeat / Toast flow. W15–18 Membership & digital purchases RevenueCat subscriptions / IAP for membership tiers and digital perks. W17–20 Odds & lines content In-app odds / lines as content / affiliate only — no in-app wagering; Illinois regulatory review. W18–20 Expanded competitions Expanded prediction-game formats and season-long competitions. 7. Critical path & schedule risk The most important scheduling point: with the build compressed to hit late summer, the launch date is governed by external dependencies, not by build throughput. The engineering work can be largely complete while the project still waits on access, hardware validation, and store review — so these items are front- loaded and tracked from Day 1, and the compressed timeline assumes they clear within roughly the first two weeks. Items that set the earliest possible launch • External access lead times — SevenRooms provisioning, Twilio A2P 10DLC carrier vetting, Apple organization enrollment, and sports-API contracting. • AudioFetch native-module integration and on-device audio testing on the venue wifi — irreducible hardware-in-the-loop validation. • Human coordination — the floor-plan / screen-inventory workshop, design-system sign-off, and compliance review. • App Store and Google Play review queues at the end of each phase. Quality & security safeguards Page 9 VICTORY & VICE Mobile App Development Plan • The security layer is reviewed by a person: Row-Level Security policies, secret handling, and the “single source of truth / no parallel guest database” rule. • Native code and integration glue stay under senior review. • Integration clients are validated against each provider’s sandbox before any feature relies on them. 8. Compliance & data-provider notes Prediction games Structured as free-to-play, no buy-in, no entry fee, with venue rewards as prizes — to stay clear of Illinois gambling regulation. The build includes a contest-rules and eligibility layer (21+ where appropriate, official rules, void-where-prohibited). The Phase 2 odds / lines feature is content / affiliate only, with no in-app wagering, and needs its own Illinois review. Client counsel should review both before launch. This is engineering scaffolding, not legal advice. Sports data API Develop against a free trial or mid-tier provider to avoid blocking on procurement, then license SportsDataIO (strong fit for free-to-play prediction contests and US leagues) or Sportradar (deepest, official data; roughly $500–$1,000+/month per sport on a B2B contract) for production. Confirm the venue’s priority leagues before signing, as pricing scales per sport. Page 10