Why I Built This
This wasn't a client brief. It was a problem I identified, a solution I designed, and a system I owned end-to-end.
The Cause
I've attended the UAE Myanmar Community's Thingyan festival before. I'd seen how it ran — sellers with spreadsheets, paper tickets changing hands, organizers with no real-time visibility into how many had been sold until the end of the day.
The 2026 festival was raising funds for disabled soldiers from Myanmar's revolution — people who sacrificed everything and had very little support. Every ticket sold mattered. Every dirham raised mattered. The organizers couldn't afford operational chaos eating into the event. I approached them with a proposal: a digital ticketing system. No paper, no duplicate claims, full real-time visibility. They said yes.
My Role & Scope
What Was Actually Going Wrong
Before this system, the organizers ran ticketing the way most community events do — manually. For a fundraiser where every seat counted, this wasn't good enough.
Duplicate Wristband Claims
A buyer could screenshot a ticket and share it — multiple people entering on one ticket. Paper tickets had no mechanism to detect or block this.
Sellers Over-Selling with No Central Tracking
Each seller tracked their own sales in separate Excel sheets. No central system meant sellers could sell more than their allocation — and nobody would know until after the event.
Zero Admin Visibility Until After the Event
Organizers had no way to know total sales until collecting spreadsheets from every seller after the event. No real-time view of what was sold, claimed, or outstanding.
No Way to Verify Authenticity
On event day, staff checked tickets visually. There was no way to verify authenticity or detect forgeries. Any printed piece of paper could potentially be passed as a ticket.
No Remote Purchase Path
Remote buyers had no way to receive tickets digitally. You had to physically meet a seller to get a paper ticket — a real barrier for the UAE Myanmar community spread across different emirates.
Financial Accountability Gap
For a fundraiser, financial transparency between sellers and organizers was critical. With separate Excel files and no audit trail, reconciliation was manual, slow, and error-prone.
Three Roles. Three Completely Different Needs.
One system had to serve an admin who needed full control, sellers who needed simplicity, and buyers who needed zero friction. Each got a different interface designed specifically for their workflow.
Admin — Full System Control
CAPABILITIES
DASHBOARD METRICS
Attendee Journey — Pre-Event to Entry
Mapped the full attendee experience to identify friction points in the old process and where the PWA resolved them.
| Stage | Discover | Purchase | Receive Pass | Pre-Event | Entry | At Festival |
|---|---|---|---|---|---|---|
| Actions | Hears about festival via community group or friend | Contacts seller, pays via bank transfer or cash | Receives digital pass link or PDF via WhatsApp | Screenshots or saves pass; checks venue details | Shows QR code — seller scans to claim wristband | Receives 5 food tickets; enjoys the event |
| Touchpoints | WhatsApp, community Facebook | Seller phone / in-person | PWA Pass Link, WhatsApp | Phone camera roll / browser | QR Scan (PWA) | On-site reception, food counters |
| Old Pain | — | Must physically meet seller | Paper ticket only | Fear of losing physical ticket | Visual check only — no fraud prevention | — |
| New Experience | — | Remote purchase enabled — no meetup needed | Digital pass via link, no app download | Pass always on phone, can't be lost | QR validates instantly, blocks duplicates | Smooth entry; no queues from paper checks |
| Emotion | 😐 Neutral | 😟 Mild friction | 😊 Relieved | 😌 Confident | 😄 Smooth | 🎉 Delighted |
End-to-End Ticket Lifecycle
Every step from ticket creation to event entry — what was previously paper and spreadsheets became a traceable system.
What I Chose and Why
Every decision was made against a real constraint — 2 weeks, 7 seller teams to train, 3,000 tickets, one live event.
App Interface & Features
Key screens showing the user experience across different roles
Before vs. After
A direct comparison of the old process and the new digital system
Role-Based Access Structure
Three separate interfaces derived from one backend — each scoped strictly to what that role needs, nothing more.
Full read/write. Can view all sellers' data, delete any ticket, modify event configs, export globally.
Own data only. Cannot view other sellers, delete tickets, or access admin settings.
Read-only pass view. No account required — ticket delivered as a shareable link.
Ticket Module Deep Dive
Batch production, early bird configs, and configurable fields gave admin full control. Sellers got a minimal two-field sell flow with instant QR generation. Error reporting let sellers flag mistakes for admin review and correction.
Why PWA?
Browser-based PWA chosen for zero install friction across 7 seller teams with diverse devices. No app store delays, instant updates, and shareable links for remote buyers — the right platform for a community event.
What Happened on Event Day
April 12, 2026. 3,000 tickets. 7 seller teams operating simultaneously. 2,000+ attendees on the day. The system held.
Zero duplicate wristband claims. Zero fraudulent entries. Zero unauthorized ticket copies successfully used.
Instead of hours collecting spreadsheets from 7 sellers, the organizer exported a single Excel file in under a minute at the end of the night.
When one seller made an input error mid-event, the admin caught it in real time from the dashboard and corrected it without disrupting the queue.
The organizers asked for a rebuild for 2027. The fundraiser ran cleanly — every ticket accounted for, every wristband tracked, every dirham traceable.
Lessons Learned
UAE Myanmar Thingyan Event Pass — Case Study
Designed & Developed as a PWA for the Myanmar Community in the UAE · April 12, 2026