P&A Wedding Invitation

Context

P&A Wedding Invitation was a 2025 client project for a couple who needed more than a static wedding website.

The invitation had to support multiple wedding events, route guests to the right RSVP flow, collect attendance details, and still feel like something made for the couple rather than a dressed-up form.

I owned the concept, UI design, frontend implementation, motion direction, Framer build, custom code components, RSVP handling, Google Sheets integration, deployment, copy, and QA. The only major piece I did not create myself was the illustration. The illustrator worked from the client’s direction, consulted with me, and handed over artwork that I integrated into the final experience.

The site is now archived because the wedding has passed, but the project is safe to share with personal details redacted.

Challenge

The main challenge was making the invitation feel personal and premium without making it fragile.

That sounds obvious until you remember the audience: wedding guests opening a link on their phones, often in chat apps, across different devices, connections, and levels of patience. The invite list was 1,000+ guests across two events, so mobile performance was not a nice extra. It was the baseline.

The project also had a hard deadline. The wedding date did not move, the project window was roughly one month, and the visual direction depended on coordination with the illustrator. I had to keep the experience expressive while making sure the moving parts could survive launch.

The RSVP system added another layer. Each event needed a separate URL, but the backend still had to collect a clean record of attendance, guest names, plus-one counts, and optional messages in Google Sheets.

Approach

I treated the invitation as a short illustrated story with a useful system behind it.

The opening cover locks the scroll and music first, then invites the guest to open the experience. Once opened, two illustrated characters appear: one representing the groom and one representing the bride. From there, the page follows a simple narrative structure. They begin on separate paths, meet at an intersection, move through their shared story, and eventually continue toward the future together.

That structure shaped the whole page:

1. Cover.
2. Prologue, with the couple on separate paths.
3. Groom and bride details, where the two paths come together.
4. Event details.
5. Couple backstory, shown as one long path with multiple milestones.
6. RSVP.
7. Event countdown.
8. Epilogue.

The decision mattered because it gave the motion a job. The animation was not there to show off Framer timelines. It carried the emotional arc of the invitation.

Motion Direction

The motion direction focused on illustration style, color, typography, and pacing.

The scroll story needed to feel rich, but not noisy. Each phase of the couple’s journey triggered different animation behavior: separate movement in the prologue, convergence when the couple meets, and a longer shared path through the backstory.

The hardest parts were timing, scroll triggers, and illustration layering. Small timing mistakes made the story feel either too slow or too mechanical. Layering also mattered because the artwork had to move as a composed scene, not as a pile of disconnected assets.

Framer made the work fast enough to ship in the timeline, but the invitation still needed careful tuning. The goal was not to preserve every flourish at all costs. The goal was to make the story feel intentional on mobile, where most guests would experience it.

Technical Execution

The RSVP flow used a mix of Framer custom code components, a custom form component, and Google Sheets.

Event selection was handled through separate URLs with query parameters. The page used that parameter as a hidden event field, so the guest did not need to manually choose the event they were invited to. Their submission still landed in the sheet with the right event context attached.

The form collected attendance, guest names, plus-one counts, and an optional message. That optional message became more useful than a normal RSVP note. Guests who could not attend could leave a message, and guests from the same event could read the message list.

That was one of the better decisions in the project. It made the backend feel less like admin plumbing and more like part of the invitation’s social experience. The sheet still acted as the attendance source, but the visible message list gave absent guests a way to participate.

Outcome

The final invitation supported the couple’s events with a mobile-first Framer experience, custom illustrated storytelling, and RSVP infrastructure tied to Google Sheets.

The invite list covered 1,000+ guests across two events. The event-specific URLs kept the guest flow simple, while the hidden event field kept the attendance data organized. After launch, the RSVP form continued to work as a guest-message surface, especially for people who could not attend.

The finished project shows the part of my work I care about most: concept, motion, and implementation working as one system. The storytelling made the invitation feel personal. The scroll timing made it feel considered. The backend made it useful when real guests started using it.

What I Would Refine Next

If I revisited the project, I would keep the core story direction intact and refine the operating layer around it.

The message list could have stronger moderation and filtering if it were intended to stay public for longer. I would also consider a small private admin view for checking RSVP status without working directly inside the spreadsheet.

For the case study itself, the next step is asset polish: finalize the redacted screenshots, choose the best motion recording, and make sure the visuals show the story sequence clearly instead of becoming a random gallery dump.