A lot of weddings don't look like that. A Nigerian or Cameroonian couple might have a traditional ceremony on Friday, a church wedding on Saturday morning and a reception that evening. Some guests come to everything. Some are only invited to the reception. Close family might be at the traditional ceremony but miss the church service because they're busy with the food. Then the caterer asks for "the final number" and you realise there isn't one number. There are three.

The mistake: one yes for the whole wedding

The most common setup I see is a spreadsheet with a single "Attending" column. It works until someone says yes and you can't tell which event they meant. Your aunt who is coming to the traditional ceremony and your colleague who is coming to the reception both count as one "yes", and the Friday caterer gets a number that includes people who will never be there.

When I started building RSVPs for WeddingBeacon, this was the first thing I got wrong. I had an attending boolean on the guest. It lasted about a week.

The shape that works

The fix is to stop treating an RSVP as something a guest has. It belongs to a pair: this guest, this event.

A simplified version in Django looks like this:

class Event(models.Model):
    wedding = models.ForeignKey(Wedding, on_delete=models.CASCADE)
    name = models.CharField(max_length=100)  # "Traditional", "Church", "Reception"
    starts_at = models.DateTimeField()


class Invitation(models.Model):
    guest = models.ForeignKey(Guest, on_delete=models.CASCADE)
    event = models.ForeignKey(Event, on_delete=models.CASCADE)
    response = models.CharField(
        max_length=10,
        choices=[("pending", "Pending"), ("yes", "Yes"), ("no", "No")],
        default="pending",
    )

    class Meta:
        unique_together = ("guest", "event")

Two useful things come out of this.

First, a guest can only answer for events they have an invitation row for. No row, no event on their page. That matters socially as much as technically. Nobody wants to find out about a reception they weren't invited to.

Second, the headcount for an event is just a count:

Invitation.objects.filter(event=event, response="yes").count()

That's the number for the caterer, one per event. If guests can bring children or a partner, store the party size on the invitation and sum it instead of counting rows.

If you're not a developer

You don't need code to use the same idea. A spreadsheet will do:

• Make one column per event, not one "Attending" column.
• Leave a cell blank if that guest isn't invited to that event. Blank means "not invited" and "No" means "invited but not coming". Keep those apart.
• Count each column on its own. That's the number for that event.
• Keep "no reply yet" as its own figure. Caterers want to know how many are still unknown, not only how many said yes.

Getting to the number you'll actually send

Caterers usually want a final figure a week or two before the day. A few things make that easier.

Set your RSVP deadline a few days before the caterer's deadline, not on the same day. You'll need that gap to chase the people who haven't replied.

Chase per event. "Are you coming?" gets a vague answer. "Are you coming to the reception on Saturday evening?" gets a real one.

Ask about children separately if your caterer prices them differently.

Leave a small buffer for the event where extra family tends to appear. Most couples already know which one that is.

Where WeddingBeacon fits

This is how RSVPs work in WeddingBeacon. You can set up to six events on one site, each guest gets a personal WhatsApp or email invite that opens their own page, and they only see and answer for the events they're invited to. Guests who say yes get a QR guest pass, and your door team can check people in from a phone, so you also know who actually turned up. If you'd like to see it, everything is at weddingbeacon.com.

Free to start at weddingbeacon.com

The problem

At a lot of weddings, especially big multi-event ones, the door is chaos. Someone has a printed list, someone else has a WhatsApp thread, and nobody is sure who has already arrived. I wanted the door team to be able to check people in from a phone without seeing anything they don't need.

Guest QR passes

When a guest RSVPs yes, they get a QR guest pass. The idea is that the QR code identifies the guest's pass without carrying their personal details, so the door team just scans and the server does the lookup.

A few things I learned:

• Keep the token unguessable and separate from the primary key. Sequential IDs in a QR code are an invitation to enumerate guests.
• Make scanning idempotent. Door staff will scan the same pass twice. The second scan should simply say the guest is already checked in, not throw an error or create a duplicate.
• Keep the screen simple. Venues often have weak reception, so the check-in screen should be lightweight and do one thing.

A check-in role that only marks arrivals

The bit I care most about is permissions. Couples add helpers through team roles: Owner, Editor and Check-in. The Check-in role can mark arrivals and see who's coming. It can't open gifts, guest notes, invites or the website.

In Django this was mostly about being strict and boring:

• Each wedding has team memberships with a role.
• Views check the role explicitly instead of relying on "is this user logged in and attached to the wedding".
• The check-in views only expose what the door needs.

It's tempting to give helpers broad access "just for the day". In practice, a cousin on the door with full edit access is how guest lists get accidentally changed at 6pm. A narrow role removes that risk.

Per-event guests

Many weddings have several events, like a traditional ceremony, a white wedding and a reception. Each guest is invited to specific events and RSVPs to each one. Modelling invitations per event, rather than a single "attending" flag on the guest, makes both RSVPs and the door list much simpler.

What I'd tell someone building something similar

1. Put permissions in the data model early. Retrofitting roles is painful.
2. Treat the door as a separate, minimal part of the app.
3. Test with real people holding real phones in a noisy room. It exposes every unclear button.

If you're curious what this looks like in a real product, it's live at weddingbeacon.com.