Jay WedPlanner

Posted on Aug 21

Handling 500-Guest Filipino Weddings: How I Designed a Guest Management System

#webdev #nextjs #database #javascript

When my cousin announced her wedding in Pampanga with 500+ guests on the invite list, I did what any developer would do: I offered to build a system instead of helping with the seating chart. This is the story of how I designed a guest management platform that handled Filipino wedding logistics — and what I learned scaling it from a Google Sheet to a real app.

The Problem: Filipino Weddings Are a Different Beast

If you've ever been to a Filipino wedding, you know the scale. We're not talking about a cozy 80-person ceremony in a garden. We're talking about a parish church packed wall-to-wall, a reception in a covered basketball court or hotel ballroom, and a guest list that grows every time your Tita mentions the wedding to her mahjong group.

But the real challenge isn't the headcount — it's the ninong and ninang system. In Filipino wedding tradition, couples select principal sponsors (godparents) who play a ceremonial and financial role in the wedding. These aren't just VIP guests — they're part of the ceremony itself, they walk down the aisle, they sign the marriage contract, and they often contribute significantly to the wedding budget.

So my guest management system needed to handle:

Hierarchical guest roles — primary sponsors, secondary sponsors, bridesmaids/groomsmen, family, regular guests
Plus-one management — because Tito will absolutely bring his friend without telling you
Table assignments with sponsor priority seating near the head table
RSVP tracking with dietary preferences and entourage participation
Door check-in that could process 500 people without a 45-minute queue

Tech Stack: Keeping It Simple but Scalable

I went with a stack I knew well and could deploy fast — the wedding was three months away.

Frontend: Next.js 14 with App Router and Tailwind CSS
Backend: Next.js API routes + Prisma ORM
Database: PostgreSQL (hosted on Supabase — generous free tier)
QR Code generation: qrcode npm package (~82M monthly downloads, battle-tested)
QR scanning at the door: html5-qrcode library (~5M monthly downloads, supports both camera and file-based scanning)
Auth: Clerk — because I didn't want to build auth for a wedding app
SMS: Twilio for RSVP reminders (because Filipinos respond to texts, not emails)

The total cost? About $12/month for Supabase + $15 for the Twilio credits we used. The domain was free with a .pages.dev deployment.

Database Schema: The Sponsor Hierarchy

The core challenge was modeling the ninong/ninang system alongside regular guest management. Here's the schema I designed:

-- Simplified schema
model Guest {
  id           String   @id @default(cuid())
  weddingId    String
  firstName    String
  lastName     String
  role         GuestRole  // SPONSOR, ENTOURAGE, FAMILY, GUEST
  sponsorType  String?   // NINONG, NINANG, SECONDARY
  tableNumber  Int?
  plusOne      Boolean   @default(false)
  plusOneName  String?
  rsvpStatus   RsvpStatus @default(PENDING)
  mealPref     String?
  qrCode       String   @unique
  checkedIn    Boolean  @default(false)
  checkedInAt  DateTime?
}

enum GuestRole {
  SPONSOR      // Principal sponsors (ninong/ninang)
  ENTOURAGE    // Bridesmaids, groomsmen, bearers
  FAMILY       // Immediate family
  GUEST        // Regular attendee
}

enum RsvpStatus {
  PENDING
  CONFIRMED
  DECLINED
  MAYBE
}

The key insight: sponsorType is nullable because only SPONSOR-role guests have it. This let me run queries like "show me all ninongs who haven't RSVP'd yet" — which, spoiler, was all of them at first.

RSVP Workflow: SMS-First Design

Here's where I had to think about the user — and by "user" I mean 60-year-old Tito who has never scanned a QR code in his life.

The flow worked like this:

Invitation phase: Each guest got a physical invitation with a unique QR code printed on a card. The QR code encoded a URL like weddingapp.dev/rsvp/{token}
SMS nudge: Three weeks before the wedding, Twilio sent a text: "Tito Boy, please confirm your attendance for Anna & Mark's wedding on Oct 12. Tap here: [link]"
Mobile RSVP page: The link opened a mobile-optimized page showing the guest's name, role, and a simple Confirm/Decline/Maybe toggle plus meal preference dropdown
Auto-table assignment: Confirmed sponsors were auto-assigned to tables 1-5 (closest to head table). Other guests were auto-assigned by batch, with manual override available
Reminder cascade: Pending guests got a second SMS one week out, then a final one three days before

The SMS-first approach was critical. Initial email-only reminders had a 12% response rate. After adding SMS, RSVP confirmation jumped to 78%. Filipinos check text messages — they don't check email.

Door Check-In: Processing 500 Guests in 20 Minutes

The reception doors opened at 6 PM. By 5:45 PM there were already 80 people lined up. I needed a check-in system that was fast enough to prevent a bottleneck but smart enough to handle edge cases.

I built a simple admin dashboard with three check-in modes:

QR Scan mode: Using html5-qrcode on a tablet — scan the code on the invitation card, instant check-in, shows table number on screen
Name Search mode: For guests who forgot their card (this happened a lot) — type the first 3 letters of the last name, tap to check in
Bulk mode: For the entourage who all arrived together on a bus — select multiple guests and check them all in at once

The html5-qrcode library was a lifesaver here. It supports both getUserMedia camera access for live scanning and file-based QR decoding for uploaded images. I used the camera mode on an iPad at the door and it decoded invitations in under 300ms — fast enough that the queue moved smoothly.

One thing I didn't anticipate: the QR codes on invitations that got folded or crumpled wouldn't scan. The fallback name search saved us. Always build a manual fallback.

What I'd Do Differently

The wedding went smoothly — 487 of 512 invited guests showed up, check-in took 22 minutes, and the seating assignments worked. But if I were to build this again:

Offline mode: The venue Wi-Fi was spotty. I'd add a PWA service worker with local caching so check-in works without internet
Pre-seated table visualization: A drag-and-drop seating chart would've saved me two hours of manual table shuffling at 2 AM
Dietary restriction aggregation: I had it in the schema but didn't build a summary view. The caterer asked for a count of vegetarians and I had to run a raw SQL query on my phone
Multi-language support: Some older relatives would've benefited from a Tagalog RSVP page. i18n from the start next time

Conclusion: Build for the User, Not the Spec

The biggest lesson from this project wasn't technical — it was human. I started by designing a beautiful, feature-rich web app. But the feature that mattered most was a simple SMS with a tappable link. The technology that saved the day wasn't a fancy framework — it was a QR code scanner that worked in 300ms.

Filipino weddings are logistically complex, but they're also deeply communal. The ninong/ninang system isn't just a hierarchy — it's a support network. My system needed to respect that structure while making it manageable. And it needed to work for a Tita who's 67 and has an old Samsung phone.

If you're building event management software, spend less time on your tech stack and more time on your user's phone. The best system is the one people actually use.

Planning a wedding or large event? WedPlanner has tools for seating charts, RSVP tracking, and guest management built specifically for large celebrations. Check out our RSVP management guide and our seating arrangement tools for more.

DEV Community