Wedding Hub

// Problem

A friend is putting together the website for a wedding in Ghana, with a guest list spread across French, Dutch and English speakers from different countries. The couple and their family are not technical, so it had to be something they could run themselves without learning new tools. Guest details live on the site, so it has to stay private and only reachable by invited guests. And because a lot of guests are traveling internationally to Ghana, they need clear info about the wedding and about the country in one place. Some guests are older or do not have their own email address.

// What I built

An invite-only flow where each guest gets a single-use code that unlocks a private guest hub with the wedding details plus practical info for guests traveling to Ghana. RSVPs are stored in a Google Sheet so the couple can manage them in a tool they already know, with the codes validated and used up server-side. The site is available in French, Dutch and English. An AI assistant answers common questions in the guest's own language and only emails the organizer for questions it cannot handle. Automated emails cover invites, confirmations and access recovery, built around real constraints like guests who do not have their own email address.

// Some decisions I made and why

1. 01Single-use codes and a signed cookie instead of a full login system

   Each guest gets a one-time invite code, and once they are in I keep them signed in with a lightweight signed cookie rather than building accounts and passwords. For a one-off wedding site that keeps it simple and cheap, and there is nothing for a non-technical guest to remember. The honest downside is the same as any code-based access: I can stop a stranger from signing themselves up, but I cannot fully stop an invited guest from passing their code on.

2. 02Google Sheets as the backend

   The couple are not technical, so instead of a database and an admin panel they would have to learn, the RSVPs live in a Google Sheet they already know. The app validates and uses up the codes server-side through Apps Script, so the sheet stays the source of truth without being something guests can reach directly. The tradeoff is that a spreadsheet is not a real database, so I keep the logic that touches it careful and on the server.

3. 03The site picks the guest's language for them

   Instead of asking each guest to choose a language, the site reads the language their browser already sends and shows French, Dutch or English to match, then remembers it with a cookie. next-intl does most of this, and the text lives in separate translation files so there is still just one site to build. For an older, less technical audience, one less thing to figure out matters.

4. 04The chatbot asks for help instead of guessing

   The assistant answers common questions in the guest's own language, but when it is not sure it emails the organizer rather than making something up about someone's travel or the wedding. I would rather it hand off to a person than give a confident wrong answer. I am still deciding which AI model to use for it.

5. 05I kept the guest data minimal and the backend locked down

   Real guest details are on the site, so I collect as little as possible and keep the backend closed off. That is both a privacy decision and a GDPR one.

// Outcome and status

In progress this summer. I'm treating this section as a build log: what I've decided, what's built, and what's still open.

// What I'd change next

Still open: which AI model to use for the assistant, and tightening the email and access-recovery edge cases as the guest list firms up.

// Links

Repo is private until the wedding. Screenshots or a short walkthrough once the main flow works.

AI usage: The guest assistant uses the Anthropic Claude API, with the exact model still to be decided. It answers from a known set of wedding FAQs and hands off to the organizers by email when it is unsure.