Rein & Mhae
A wedding site that feels authored and runs the whole RSVP, from guest lookup to confirmation email.
A wedding site is two things at once: an emotional artifact the couple is proud to send, and an operational tool that has to collect accurate answers from a hundred-plus guests. Most builds nail the first and bolt a Google Form onto the second. The design brief here was to make the RSVP feel like part of the story, so guests find their own name, choose their meal, and get a reply, without ever seeing a form that looks like data entry.
Agency rule: vanilla HTML, CSS, and JS, no framework and no backend server. Yet the site had to match guests against a real invite list, persist every answer, send confirmations, and hand the couple an editing surface they could run with zero technical help. Every system had to be assembled from a static host and a Sheet.
The couple, and the hundred-plus guests who need to reply without friction.
Product design that carries its own backend: information architecture, a guest flow, and an editing surface a non-coder can run.
- A guest looks themselves upNames are matched against the real invite list, not a blank form.
- Response saved, and editableEvery RSVP is written to a Sheet the couple can see, and a guest can come back and change their reply instead of being locked to one submission.
- Confirmation sentThe guest gets an email confirming their response automatically.
- The couple edits it themselvesA built-in CMS lets them change content without a developer.
Guest lookup instead of an open form. The obvious build is a form with a name field. Instead the first interaction is finding yourself on the list, which does three things a form cannot: it sets an intimate tone (the site already knows you are invited), it removes the anxiety of wondering whether you filled it in right, and it keeps the data clean because responses attach to real invite records rather than free text. One UX choice carries the mood and the data quality at the same time.
The RSVP state lives in a Sheet, which is legible to the couple but has no validation layer. I would keep the Sheet as the human-readable record and add a thin validation pass in front of it, so a mistyped guest count or a double submit is caught before it lands, without taking the spreadsheet away from the people who actually use it.