01 — VENUE
The dashboard
Signs in at /admin. Creates weddings, pastes guest lists, watches RSVPs land, uploads the delivery. Granted by the platform owner, never self-serve.
MULTI-TENANT PLATFORM
One platform a wedding venue runs for every wedding it books. Each couple gets their own bilingual site — the invitation, a per-household RSVP that counts itself, and the photos and film delivered properly afterwards — all under the venue’s name.
Demo wedding — Lily & Tan, September 2026. Switch EN/TH in the header. A static capture of the guest site: the venue dashboard, the couple portal and the one-time-code sign-in run on the real deployment.
A wedding lives in five places at once: a LINE group for the guest list, a Google Form for the RSVP, a printed card for the invitation, a Drive folder for the photos that expires when someone clears their storage, and a phone call to the venue every time a number changes. Nobody owns the count. The real headcount lands the week of the wedding.
This replaces all five with one platform. The venue creates a wedding, pastes the guest list in as one column, and the invitation links generate themselves. Guests reply through their own link. The photographer’s delivery arrives on the same site weeks later, with the venue’s name on it, in front of two hundred people who are all about to plan something.
This is built for the business that books the wedding, not for a single couple.
A wedding currently lives in five places at once, and none of them owns the number that actually matters.
The template is the working platform, plus the path to owning your own copy of it.
Everyone signs in the same way — email plus a one-time code, no passwords anywhere. What differs is which door, and how permission was granted before they got there.
01 — VENUE
Signs in at /admin. Creates weddings, pastes guest lists, watches RSVPs land, uploads the delivery. Granted by the platform owner, never self-serve.
02 — COUPLE
Signs in at /portal. Edits their own story and sees their own guest list — and nothing else. The venue adds their email to unlock it.
03 — GUEST
Opens /i/<token> and is greeted by household name. The link is the guest list — no account to create, nothing to install.
Each wedding carries a phase switch. One click from the dashboard changes what every guest sees. No rebuild, no second site.
PHASE 01
Engagement gallery, the couple’s story, a live countdown, and the RSVP form.
PHASE 02
Order of the day, directions and a map link. Replies are closed; the page is a schedule.
PHASE 03
The full gallery and the highlight film, with full-resolution downloads.
ALWAYS
Every phase ships in both, switchable by the guest — including the invitation itself.
| Stage | What happens |
|---|---|
| Create the wedding | One record that carries everything downstream |
| Paste the guest list | One household per line, and the links generate themselves |
| Guests reply through their own link | The link is the guest list |
| The count closes itself | The number the kitchen gets is the number that is true |
| Flip the phase on the day | One switch changes what every guest sees |
| Deliver the photos and the film | The moment the venue is actually selling |
Every wedding is visually its own, while the platform underneath stays one codebase.
Each wedding’s data is fenced off at the database level, not by application code remembering to filter.
The delivery is the sales channel. Everything else on the platform exists to make sure the venue owns that moment.
Worth knowing before you commission one.
| Frontend | Next.js 16 (App Router) and TypeScript, deployed on Vercel |
|---|---|
| Backend | Supabase — Postgres, passwordless auth, row-level security per wedding |
| Media | ImageKit — upload, transform, thumbnails, video posters, adaptive streaming, signed URLs |
| Resend SMTP on a verified domain for the one-time sign-in codes | |
| Languages | English and Thai throughout, guest-switchable, Thai-aware typography |
| Tenancy | Multi-tenant — unlimited weddings under one venue account |
Captured from the live demo wedding. This is the platform as it actually renders, not a mock-up.



This is built for the business that books the wedding, not for a single couple. The who-this-is-for section above lists the three cases it fits most directly.
No password, ever. A guest opens their invitation link, enters their email, and receives a one-time code. That is the whole sign-up. The link itself is the guest list — nobody has to be added by hand.
A household link locks to the first account that signs in with it. Anyone else holding a forwarded copy is told it has already been claimed and sees nothing else — not the household name, not the reply already sent. The venue can unlock it from the dashboard.
That is the point. Unlimited weddings under one dashboard, each with its own palette, monogram, guest list and gallery, and each isolated at the database level.
Next.js 16 and TypeScript on Vercel, Supabase for the database, passwordless auth and row-level security, ImageKit for every image and video, and Resend for the sign-in codes. Hand-built, with no site builders in the stack.
Every step listed in the sidebar and in the overview table is part of how this platform actually runs. There are 6 of them, and each one is described in the How It Works panel beside the article — expand any row to read what it does.
That is the intended path. Nothing ships as-is — it gets rebuilt around your brand, your copy and your goals. Start a project and describe what you are building.
Wedding Platform gets rebuilt around your brand, your copy and your goals — and you own the build outright. Tell me what you are building.
Start a project Browse the rest of the shelf