SPOSAI · 2026

I designed the guest experience for our own destination wedding.

Every page our 103 guests saw, from the RSVP to the registry, designed and built by me.

01 / MY ROLE

I owned everything our guests saw and interacted with.

My role: I designed the guest experience (visual direction, type and palette, information architecture, RSVP, registry, travel and schedule); Cyrus built the admin side (dashboard IA, design system, admin tools). Two people, one product, built with C
VIEW LIVE WEDDING WEBSITE
VIEW LIVE WEDDING WEBSITE

02 / THE PROBLEM

Existing wedding tools managed the pieces but not the overall experience.

We reviewed the tools out there. Each one handled the admin side or the guest site, never both well.

03 / THE INSIGHT

Planning a wedding isn’t one workflow. It’s dozens happening all at once.

Before the trip: where am I staying? How do I get there? What should I wear?
Before the trip: where am I staying? How do I get there? What should I wear?
During the wedding: where do I need to be? When do I need to be there? How am I getting there?
During the wedding: where do I need to be? When do I need to be there? How am I getting there?
When plans change: where's the latest information? Has anything changed? What do I need to do?
When plans change: where's the latest information? Has anything changed? What do I need to do?

THE GOAL

Guests always know what to expect, where to go and when to be there, without having to ask the couple.

04 / DESIGN DIRECTION

Our guests didn’t need the planning chaos. They needed to feel guided and cared for.

Clear and guided: the right information at the right time.
Personal by design: it feels like the couple, not a template.
Part of the experience: the celebration begins before guests arrive.

05 / THE RSVP

One RSVP for a three‑day weekend.

61 of the 79 guests who came RSVP’d here themselves. We recorded the rest for relatives without internet access.

RSVP code entry screen on a phone: six boxes for the invitation code, with a Lost your code link.

01

ONE CODE PER HOUSEHOLD
No account or password. The code on the invitation opens the whole family’s RSVP.

RSVP contact step on a phone: progress dots near the end, two fields, and Back and Next buttons.

02

ONE QUESTION PER STEP
Events, guests, travel, then a review. Progress dots show how much is left.

RSVP events step on a phone: All Events and three events, each ticked, with Back and Next buttons.

03

ANSWER PER EVENT
Guests pick the events they’ll attend, so the couple gets a real headcount for each.

06 / THE REGISTRY

Giving a gift should feel as considered as the rest of the celebration.

Built into the wedding site, not a separate registry: amount, card, note, review, then a Stripe checkout.

07 / TRAVEL AND SCHEDULE

Making a three-day wedding easy to follow.

Day → Time → Event → Location → Essential details

Shuttle times, rooms and events change right up to the wedding day. So I designed every guest card to read straight from the couple’s dashboard. When they move a shuttle, guests see the new time without anyone updating the site. I designed the guest side; Cyrus designed the dashboard.

I designed for plans that change.

08 / CONNECTED LOGISTICS

Shuttles: time first, then route and seats, the order a guest checks them in.
Shuttles: time first, then route and seats, the order a guest checks them in.
Rooms: guests enter their invitation code and see only their own room.
Rooms: guests enter their invitation code and see only their own room.
Schedule: built from the couple's events, so a change never leaves an old copy.
Schedule: built from the couple's events, so a change never leaves an old copy.

09 / HOW I BUILT IT

Visual system: type, palette and spacing set like the invitation itself, not a template.
Information architecture: each page answers one guest question: where, when, or what to wear.

I designed and built the guest site with Claude Code.

Two flows: RSVP and registry, one question per step, with a review before anything is sent.

10 / OUTCOME

From a personal planning problem to a product used in the real world.

Sposai was built around our own destination wedding, giving us the opportunity to use the product end-to-end throughout a real three-day celebration, not a simulated scenario.

103 guests invited to our own destination wedding in Puglia.
79 guests attended, across three days of events in July 2026.
65 of 65 invitations answered; 61 of the 79 guests RSVP'd themselves.
4 couples in the beta, each at a different stage of planning.
EXPLORE THE FULL PRODUCT

Our wedding · Puglia, Italy · July 2026

11 / REFLECTION

Designing beyond individual screens.

The biggest shift in my thinking was learning to design the connection between systems and experiences, not just the screens in between.

NEXT CASE STUDY — SPOSAI LANDING PAGE

I redesigned Sposai’s landing page around one promise and one action.

Six versions of the first screen in four weeks: how I cut the hero from five controls to one button and turned a features list into a running order.

The Sposai landing page on a phone, open on its hero: The calm way to plan a wedding
VIEW CASE STUDY