Fuda - Event Ticketing & On-site Payment Platform (for Global Sound)

Overview

A B2B platform that enables music event organizers to manage ticket sales, event check in, merchandise payments, and revenue distribution within a single service. I designed optimized experiences for three distinct user contexts: attendees on smartphones, organizers on desktop, and event staff on iPhone.

For in person payments on the event day, a dedicated iOS app supports Tap to Pay on iPhone, allowing staff to accept contactless payments directly on an iPhone without additional hardware. The app works seamlessly with the web platform through a single shared account.

Background & Problem: The Limits of Custom Code and Entrance Flow Bottlenecks

The idea for Fuda was born out of my hands-on experience running live music events for a vocal music group called "Global Sound" since 2024. It started when the group asked me to build a simple event website. For the first event, I hard-coded custom forms for inquiries and ticket sales, and everything went smoothly. However, when the second event came up, I hit a massive wall: the event layout was completely different, meaning I had to copy-paste and rewrite the exact same form logic all over again from scratch. It was unsustainable. The moment discussions for a third event started, I knew this manual approach wouldn't scale. I stopped writing custom forms and realized, "I need to build a shared platform." Luckily, a popular, low-fee ticketing service widely used in our community announced its closure around the same time, giving me the perfect green light to build Fuda.

While architecting the platform, I wanted to target and eliminate the specific, structural UX flaws I frequently encountered as an attendee using major legacy apps like LivePocket or PassMarket.

① The "Mandatory Login" Wall at Checkout

When a friend sends you a link to buy a ticket, being forced to create an account or log in before paying is the ultimate conversion killer. Fuda completely removes this friction. Designed from the ground up for quick mobile purchases, spectators can buy tickets in under 5 minutes without ever logging in — all they need to enter is an email, name, and their payment method (Credit Card or PayPay).

② Gate Traffic Jams: Unresponsive QR Code Loads

In underground live houses or packed venues, cellular reception is notoriously terrible. I constantly saw entrance gates get backed up because fans couldn't load their check-in QR codes. To solve this real-world operational mess, I built a native iOS app for organizers and gate staff. As long as you open the app where there's signal, it caches the entire attendee list into a local database. The UI explicitly states exactly when the data was synced, allowing staff to smoothly scan QR codes and check people in completely offline for events of a few hundred attendees.

③ Gate Operation Vulnerabilities in Edge Cases

When a spectator didn't take a screenshot in advance, or their phone died right at the entrance, legacy systems made it incredibly painful for staff to verify their purchase. Fuda's staff app keeps the full attendee list instantly accessible. Even without a QR code, staff can just search the buyer's name or email to check their "Paid/Unpaid" status and let them in without making a scene.

Strategic Trade-offs: Shipping the Core, and Cutting the Rest

To launch a production-ready app in just 3 months, I focused entirely on shipping the absolute essentials I needed for our upcoming live event (smooth web checkout, fast check-ins, and on-site payments). I didn't hold back on the core, but I ruthlessly cut out secondary features that legacy ticket sites usually have.

First, I completely skipped building an event discovery portal or list page. Every event gets its own unique URL, and organizers are expected to drop that link directly into their own channels—like their group’s X (Twitter) account—to drive sales. I also skipped building a spectator app, and avoided complex features like reserved seating, which would jump dev costs for small-scale events. Even our main marketing landing page was left as a bare-minimum placeholder showing fees and basic features, leaving copy and conversion optimization for later.

Instead, I invested my limited time heavily into on-site "Tap to Pay" integration. There are always people who show up last minute on the day of the event, and in our music scene, "cash-only for door tickets" was the accepted norm. In today’s digital world, that felt broken. I wanted to be the one to push the digital wave forward in this community. So, I fought to bake contactless smartphone payments right into the MVP to see how it would actually perform in the wild.

Service Design: Revenue Isolation and Gate Staff Security Controls

Initially, I designed the ecosystem around just two roles: Spectators and Organizers. But as I was writing the code for the organizer dashboard and saw the actual live revenue, payout numbers, and historical customer data populating the screen, I felt a strong gut-level hesitation.

Without a separate staff role, checking in guests at the gate meant giving my friends and volunteers the exact same master login credentials. That meant exposing our entire event revenue to anyone helping at the door. As an organizer, my immediate reaction was, "I really don't want door staff seeing our total financials."

Looking ahead to scaling the platform for external groups, this became an absolute dealbreaker. Larger organizers hire external gig workers or volunteers for gate operations. Blocking access to financial data and customer PII wasn't just a nice-to-have feature; it was a fundamental security requirement for the platform's credibility. The "On-Site Staff" role was born right there on the dev server—hiding the financial dashboard entirely and limiting the UI strictly to two actions: QR scanning and Tap to Pay collection.

• Minimum Privilege Access: Revenue dashboards and customer PII are completely hidden to protect financial data and privacy.
• Hyper-focused Scope: The UI is restricted entirely to two actions—QR code scanning and on-site Tap to Pay collection.
• Gate-Optimized UI: Engineered for fast, high-stress gate environments with a layout built for one-handed use, clear color-coded status checks, and total offline resilience.

Product Design

Performer Attribution Systems Built for Indie Music Networks

There was a critical cultural nuance that generic ticketing sites completely ignore, but is an absolute requirement for student and independent vocal groups: tracking member sales quotas (knowing exactly which performer brought in which attendee). On legacy platforms, buyers have to manually type the performer’s name into a generic "Notes" textbox at checkout. This leaves organizers with a messy text file that they have to manually clean and tally up after the show.

Fuda fixes this natively. Leveraging our organization-hub structure, we built a system that lets organizers generate unique tracking links with embedded URL parameters for each performer with a single click.

Performers just send their unique link to friends over LINE or text. When a fan buys a ticket, the sales count automatically maps to that specific performer on the organizer's dashboard in real time. It removes the extra "Who invited you?" dropdown step for the buyer entirely, matching how people actually communicate today. By leaning into this niche cultural workflow, Fuda turned an administrative burden into a seamless, high-value feature.

Intentional Experience Design: Investing in Emotion Beyond Pure Function

While a static QR code is perfectly sufficient to facilitate event entry, this refactor goes beyond pure functional requirements. It is a deliberate piece of experience design aimed at driving emotional engagement and increasing product retention. In engineer-driven, constraint-first environments, micro-interactions like this are often deprioritized. This project demonstrates my approach to intentionally investing in design polish to elevate a core user loop.

1. Hypothesis & Intent

The goal was to give users a tangible sense of ownership—the feeling that the ticket is securely inside their personal wallet the moment the purchase completes—while building anticipation for the event. I wanted to transform entry from a bureaucratic chore into the true beginning of the event experience.

2. Design Decisions & Mechanics

Using motion/react shared layouts, I engineered the opening and closing transitions using a single, reversible timeline. This kept the state logic computationally lightweight and bug-free, ensuring fluid consistency and a sense of reassurance even if a user cancels the interaction mid-way. For multi-ticket orders, users can swipe through a full-bleed horizontal carousel that ignores standard wallet boundaries. When closed, the tickets stack together organically, acting as a physical metaphor for being safely "tucked away" in a real wallet.

3. Constraints & Guardrails

Because added polish introduces potential frailty, I established strict technical boundaries before writing any code:

• Zero Core Logic Changes: The interaction lives entirely on the presentation layer. The underlying scanning and entry validation logic remains completely untouched.
• Accessibility First: If a user has prefers-reduced-motion enabled at the OS level, the animation instantly deactivates while maintaining the exact same layout and information architecture.
• Cognitive Load Control: The introductory motion sequence fires only upon the initial purchase via cookie tracking to teach the interaction. Subsequent views bypass the intro to prioritize raw utility.

Ultimately, meaningful product design isn't about chasing flashy aesthetics, but about drawing a precise line where you can inject delight without compromising system integrity.

Design Engineering: Prompt-Driven Pair Programming and Interface Directing

Shipping a web app, a native iOS app, multi-tenant databases, and payment routing solo in 3 months required completely changing how I interact with code. I treated the AI not as a copy-paste generator, but as a design-critique and engineering partner to speed up our workflow.

During this project, I moved away from manual keyboard typing inside the editor. I established the structural foundations and application state architecture entirely by consulting conversational models (Claude) via natural language. On the frontend, I integrated the modular design library shadcn/ui, which drastically accelerated layout deployment speeds.

Furthermore, I utilized voice-directed tools like "Aqua Voice" alongside element-targeting extensions like "Agentation" as my primary production workflow. I directly clicked visual elements in the browser view to capture structural identifiers, passing direct verbal instructions like "reduce this padding block" or "align this container to the right" to let the AI process and refactor the underlying codebase automatically, bypassing manual directory searching.

To navigate complex system states, I prompted the AI using specific functional personas (e.g., "provide layout variants as a UX designer," "evaluate constraints as a PM"). I audited the resulting variations against system consistency, managing visual layouts and cross-screen consistency through active prompt direction while the AI handled rapid text generation.

Retrospective: Live Trial Validation and Real-World Maintenance Iterations

Following the 3-month sprint, Fuda successfully concluded its first live production trial managed by an external operations team. Operating the terminal setups during high-volume gates with zero transaction errors across all card-present entries validated the platform's reliability. This real-world deployment helped identify our next operational milestones and system constraints.

① International Gateway Limitations: Regional Android Support Constraints

While "Tap to Pay on iPhone" worked beautifully as our core feature, I hit a regional technology constraint mid-development: Stripe’s Tap to Pay SDK does not support Android devices in the Japanese market yet. Even with Japan's massive iPhone market share, leaving Android organizers and users unable to take digital door payments felt like a major product constraint. Navigating these regional payment infrastructure boundaries will be our next major focus area.

② Real-World Maintenance Adjustments (Currently in Progress)

Based on post-event feedback from live testing, I am actively executing the following product updates:

• Payout Schedule Optimization: Restructuring the automated balance clearing and platform fee processing mechanics to support the immediate cash flow requirements of independent music clubs.
• Gate POS Dashboard Refactoring: Enhancing the information density and typography contrast of the iOS staff view to ensure entrance workers capture aggregate registration numbers and terminal tallies at a glance.
• Platform Visual Polish for Public Release: Refining the visual design across the global layout to transition the tool from an internal setup to a polished, multi-tenant SaaS ready for external groups.

③ Figma MCP: Turning Design into the Source of Truth

While this sprint relied on a code-first rapid iteration cycle, the emergence of "Figma MCP" (Model Context Protocol) introduces a highly efficient alternative Linking development terminals directly to Figma's underlying vector trees via MCP allows design files to act as the absolute source of truth. Changes can sync directly between canvas properties and front-end components, preserving layout intent with zero manual conversion debt. I intend to build this next-generation pipeline on day one of my upcoming projects.