One RSVP for a Multi-Event Wedding

Vowframes could “handle RSVPs,” but that short phrase hid a bad guest flow.

Each event could collect its own response. A guest invited to the mehendi, wedding, and reception had to enter the same details three times. The data model looked tidy because attendance belongs to an event. The guest experience felt repetitive because a person receives one wedding invitation.

Indian weddings make this harder. Different guests see different combinations of events. Families often respond together. One member may attend the sangeet while another joins only the wedding. Plus-ones, meal questions, and travel details add more variation.

We rebuilt the flow around one RSVP submission.

The invitation decides what appears

A guest opens an invite link or enters an invite code. Vowframes resolves that code into an invite group, its members, and the events available to them.

The RSVP form then shows the correct event set. A guest invited only to the reception sees the reception. A family invited to four events can answer all four in the same flow.

This keeps event privacy inside the RSVP experience. The frontend does not ask the guest to choose from the wedding’s complete schedule.

One submission contains event-level answers

The backend stores a parent RSVP submission for the guest or invite group. Individual event responses sit underneath it.

That structure supports both sides of the product:

• the guest completes one form;
• the couple still gets attendance per event;
• group members can have different answers;
• custom event questions can stay attached to the right event;
• an existing submission can be reopened and updated where editing is allowed.

The system preserves the useful event-level data without exposing the database structure to the guest.

Families are a real product object

Many invitation systems treat a family as several independent users who happen to share an address. Wedding invitations often work the other way around. The family or household receives the invitation, then its members decide who will attend each event.

Vowframes uses invite groups to represent that shared invitation. The group can contain several named guests, an invite code, event eligibility, and rules for additional guests.

This reduces duplicate data entry for the couple and matches the way invitations are discussed outside the software.

The couple needs a consolidated view

Guest convenience only solves half the problem.

The admin area needs to answer operational questions:

• which invite groups have replied;
• how many people are attending each event;
• which members of a group declined a specific event;
• who has not responded;
• whether a guest changed an earlier answer;
• which event needs a follow-up.

Vowframes provides an overall RSVP summary with event-level drilldowns. The couple can manage the wedding from one response model instead of reconciling several forms and spreadsheets.

Compatibility mattered

Existing weddings already had event responses. Replacing the RSVP model could not invalidate those links or erase the couple’s data.

The migration therefore needed a compatibility path for earlier records. Guest pages had to render older weddings while new weddings used the unified flow. The public site and admin also had to agree on event eligibility so one side did not show an event the other side considered private.

What the new model changed

The product goal was fewer steps for guests and better information for couples. A flatter RSVP form would have made the guest experience shorter while losing event detail. Keeping separate forms would have protected the old schema while preserving the friction.

The parent submission supports both needs. A guest responds to the wedding in one sitting, while the family organizing it keeps the event-by-event plan. The extra complexity now sits in Vowframes instead of appearing three times in the guest’s browser.

Building with AI: AI can write event models, serializers, and forms quickly once the object boundary is chosen. It cannot decide from normalization alone whether the user's object is an event response or one wedding invitation. I made the invitation the parent action, then used model validation, tenant-scoped endpoints, and compatibility tests to stop generated code from exposing an event or attaching an answer to the wrong submission.

One response, with event detail

The implementation names the distinction directly. RsvpSubmission is the one guest or group action. RsvpEventResponse holds the yes/no state and attendee count for one eligible Function. RsvpAnswer can belong either to the submission or to a specific event response, and model validation rejects an answer attached to the wrong event or submission.

The public flow first resolves:

GET /api/<tenant>/rsvp/context/?code=<invite-code>

It then creates or updates the parent submission through /api/<tenant>/rsvp/submissions/. The context response returns only the invite's eligible events; the browser never receives the complete private schedule and filters it on its own.

I exercised RSVP, invite, and event behavior together: two event responses in one submission, a cross-tenant event, “no” with a non-zero attendee count, per-event questions, code-only invites, group edits, and the couple's drilldowns.

Guests now fill fewer repeated forms while the family keeps the event-level counts needed to run the wedding. Database constraints and tenant-scoped endpoints prevent a frontend change from turning one invitation back into unrelated responses or revealing an unassigned event.