Fuda

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.

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.