From first sale to platform —
ten phases of WolfTix.
WolfTix is a ticketing platform for casinos, built incrementally in ten phases. Each phase answers a single question: what can the casino do once this phase ships? This document shows every phase, why we build in this order, and what we deliberately leave for later.
The ten phases at a glance
Click any phase to jump into its details below.
| # | Phase | What the casino can do after | Requires |
|---|---|---|---|
| 1 | Sell + Attend + Track | Sell tickets online, admit patrons with QR, track sales and attendance, close events financially. | — (start) |
| 2 | Real Venues | Sell reserved seating with interactive seat maps, full comps and holds, multi-tier pricing. | Phase 1 |
| 3 | Operations Maturity | Operate without constant internet in the hall, sell on-site at the box office, and deliver tickets through Apple/Google Wallet. | Phase 2 |
| 4 | Patron Experience | Give patrons reasons to come back: favorites, reviews, sharing, social proof. | Phase 1 |
| 5 | Marketing & CRM | Actively drive demand — targeted campaigns, segments, patron CRM, attribution. | Phase 4 |
| 6 | Promoter Partnerships | Host events with external promoters (Live Nation, AEG): scoped portal, splits, automatic payouts. | Phase 1 + Phase 2 |
| 7 | High-Demand Onsales | Survive a Beyoncé-grade onsale: queue, anti-bot, P2P transfer, controlled resale. | Phase 3 |
| 8 | Add-ons & Ancillary | Grow revenue per patron beyond the ticket: parking, food, merch, VIP packages, groups. | Phase 2 + Phase 3 |
| 9 | Enterprise Scale | Pass enterprise procurement: SOC 2, pentests, white-label, public API, SLA. | Phases 1–3 stable in production 6+ months |
| 10 | Platform / Ecosystem | WolfTix as an ecosystem: marketplace, developer portal, partner integrations, reseller program. | Phase 9 |
The order isn't strict 100% of the time. Some phases can run in parallel (e.g. Phase 2 and Phase 4 — different teams, different surfaces). The hard sequential dependencies are 1 → 2 → 3 → 7 and Phase 6 requires both Phase 1 and Phase 2.
Four rules that drive the order
Every decision about “what goes in which phase” comes back to one of these.
Money path before delight
Sales, settlement, refunds first (Phase 1). Marketing, campaigns, social proof later (Phase 4–5). Without a working money path the casino doesn't sign.
Operations before delight
Sales and entry must work (Phase 1, 3) before favorites, reviews, sharing (Phase 4). A broken gate kills the event on day one.
Own first, others second
Phases 1–5: the casino sells its own events. Phase 6 brings external promoters in. Partnerships need mature internal processes first.
Compliance from day 1
Audit log, refund approvals, role enforcement — all in Phase 1. You can't backfill an audit trail. A missing week is a gap you can't close.
Sell + Attend + Track
Sell tickets online, admit patrons with QR, track sales and attendance, close events financially.
Requires: — (start)
The first real casino sells its first event online. A patron buys a ticket, shows up at the casino, walks in past the scanner. The casino tracks sales and attendance in real time. After the event, finance closes the books and exports CSV to accounting.
- Create events in the admin panel (date, venue, description, photos, ticket types)
- Sell tickets to patrons over the web (Stripe payment)
- Apply automatic tier-based discounts — patron account is linked to the casino loyalty system (PMS), so a Gold-tier patron sees a Gold price at checkout
- Admit patrons to the venue — scanner validates the QR and says "let in" / "deny"
- See real-time KPIs: tickets sold, attendance, revenue
- Close an event financially (gross / fees / net) and export CSV to accounting
- Refund a ticket through a Finance-approval workflow
- Talk to patrons via an embedded support chat
- ●Patron signup / login
- ●Link patron account to the casino loyalty system (PMS) — tier-based pricing
- ●Event list and event detail page with a simple sector map (no interactive seat picker — Phase 2)
- ●Checkout: pick ticket type → Stripe payment → email with PDF ticket and QR code
- ●In-app wallet: list of my tickets with the QR ready to show at the gate
- ●Orders history
- ●Support chat (logged-in patrons only)
- ●Dashboard with live KPIs
- ●Event create / edit / archive
- ●Simple seat management — sectors with capacity (interactive map — Phase 2)
- ●Users and roles (7 predefined roles, listed below)
- ●Approvals queue (refunds above a threshold need Finance Admin)
- ●Refund flow: admin initiates → Finance approves → Stripe refunds
- ●Sales and attendance reports (with CSV export)
- ●Settlement per event — generate gross / fees / taxes / net report, lock, export GL-mapped CSV
- ●Audit log — every sensitive action recorded with who / when / what
- ●Support inbox
- ●Organization and venue management (fee percentages)
- ●Minimum comps (admin issues a free ticket to a specific person)
- ●Minimum holds (admin marks a seat or quantity as held — e.g. for VIP)
- ●Admin-initiated ticket transfer between patrons (peer-to-peer transfer — Phase 7)
- ●PWA installable on a phone
- ●QR scan from camera plus manual code entry
- ●Validation: valid / used / duplicate / wrong-event / cancelled
- ●Online only (offline mode — Phase 3)
- ●Each scan flows immediately to the admin dashboard (live attendance)
- ●Multi-tenant database (one instance serves many casinos)
- ●File storage (event images — prepared for CSV and contracts later)
- ●Transactional email and SMS
- ●Stripe Connect — the casino becomes a connected account, we earn through application_fee
- ●Integration with one casino loyalty system (e.g. Konami SYNKROS) — read patron tier
| What | Returns in |
|---|---|
Interactive seat map (clickable individual seats) 3–4 months of work; sectors are enough for a first sale. | Phase 2 |
On-site sales (Box Office, walk-up tills) Different operational problem — physical tills, will-call queues, hardware. | Phase 3 |
Offline scanner mode Requires sync protocol; an iPhone with LTE is enough to start. | Phase 3 |
Apple Wallet / Google Wallet PDF + in-app wallet preview is enough for MVP. | Phase 3 |
Promo / discount codes Requires the marketing infrastructure (segments, campaigns). | Phase 5 |
Favorites, reviews, sharing They don't make money in the basic sell-attend-track phase. | Phase 4 |
Marketing campaigns and CRM Needs the data Phase 4 collects. | Phase 5 |
Add-ons (parking, food, merch) Needs a separate catalog and checkout flow. | Phase 8 |
External promoter portal In Phase 1 the casino sells its own events. | Phase 6 |
Waiting room and anti-bot protection Expensive and unnecessary for the first sales. | Phase 7 |
Full settlement workflow with promoter splits In Phase 1 the casino is the sole party. | Phase 6 |
Patron-to-patron ticket transfer Requires anti-fraud (QR-theft protection). | Phase 7 |
Everything else assumes this works. Without working sales there is nothing to extend with seat maps. Without settlement the casino can't sign for production. Without the audit log we don't meet the regulatory bar for a gaming-and-financial business. This is the foundation — when it's missing, every later phase hangs in the air.
- Admin Master — Everything + manages roles. Cannot edit own role (lockout protection).
- Finance Admin — Approves refunds, locks settlements, sees finance reports.
- Event Coordinator — Creates and edits events, issues minimum comps and holds.
- Ticket Manager — Initiates refunds, handles support, looks up orders.
- Auditor — Read-only across the whole system.
- Patron — Buys tickets, uses the wallet, talks to support.
- Scanner Operator — Scans tickets at the gate. Nothing else.
- A real casino sells at least 100 real tickets to one real event (not test data).
- End-to-end without error: buy → email with PDF → walk in past the scanner.
- Dashboard shows live sales and attendance during the event (latency under 5 seconds).
- Finance Admin generates a settlement, locks it, exports CSV — entirely in the UI, no SQL.
- Full refund cycle: patron asks → admin initiates → Finance approves → Stripe refunds → patron sees the money.
- Every sensitive action is in the audit log (who / when / what / before-after values).
- All 7 roles enforced server-side (a lower role cannot perform a higher action even via direct API).
- Stripe Connect onboarding complete (KYC done, payouts active).