01 Venue
The dashboard
The venue signs in at /admin to create weddings, paste guest lists, watch RSVPs land, and upload the delivery. The platform owner grants access. It’s never self-serve.
Multi-tenant platform
One platform a wedding venue runs for every wedding it books. Each couple gets their own bilingual site under the venue’s name, with the invitation, a per-household RSVP that counts itself, and the photos and film delivered properly afterwards.
Demo wedding: Lily & Tan, September 2026. Switch EN/TH in the header. This is a static capture of the guest site. The venue dashboard, the couple portal, and the one-time-code sign-in run on the live 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 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, with no passwords anywhere. What differs is which door they use, and how permission was granted before they got there.
01 Venue
The venue signs in at /admin to create weddings, paste guest lists, watch RSVPs land, and upload the delivery. The platform owner grants access. It’s never self-serve.
02 Couple
The couple signs in at /portal to edit their own story and see their own guest list, and nothing else. The venue adds their email to give them access.
03 Guest
A guest opens /i/<token> and is greeted by household name. The link is the guest list. There’s no account to create and nothing to install.
Each wedding carries a phase switch. One click from the dashboard changes what every guest sees, with no rebuild and no second site.
Phase 01
Engagement gallery, the couple’s story, a live countdown, and the RSVP form.
Phase 02
The order of the day, directions, and a map link. Replies are closed, and the page is a schedule.
Phase 03
The full gallery and the highlight film, with full-resolution downloads.
Always
Every phase ships in both, including the invitation itself, and the guest can switch between them.
| 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’s true |
| Flip the phase on the day | One switch changes what every guest sees |
| Deliver the photos and the film | The moment that sells the venue |
Every wedding is visually its own, while the platform underneath stays one codebase.
Each wedding’s data is fenced off at the database level, so it doesn’t depend on 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, and row-level security per wedding |
| Media | ImageKit: upload, transform, thumbnails, video posters, adaptive streaming, and signed URLs |
| Resend SMTP on a verified domain for the one-time sign-in codes | |
| Languages | English and Thai throughout, switchable by the guest, with Thai-aware typography |
| Tenancy | Multi-tenant: unlimited weddings under one venue account |
Captured from the live demo wedding. This is the platform as it renders.



This is built for the business that books the wedding, not for a single couple. The “Who this platform is for” section above lists the three cases it fits best.
No password, ever. A guest opens their invitation link, enters their email, and receives a one-time code. That’s the whole sign-up. The link itself is the guest list, so 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’s already been claimed and sees nothing else. The household name and the reply already sent stay hidden. The venue can clear the lock from the dashboard.
That’s the point. It runs 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 handles the database, passwordless auth, and row-level security. ImageKit serves every image and video, and Resend sends the sign-in codes. It’s hand-built, with no site builders in the stack.
Every step in the sidebar and the overview table is part of how this platform runs. There are 6 of them, and the “How it works” panel beside the article describes each one. Expand any row to read what it does.
That’s the intended path. Nothing ships as is. I rebuild it around your brand, your copy, and your goals. Start a project and tell me what you’re building.
I rebuild Wedding Platform around your brand, your copy, and your goals, and you own the build outright. Tell me what you’re building.
Start a project Browse the rest of the shelf