VAL WEDS FATIE — THE GATEFOLD INVITATION

Val WedsFatie

Role
Designer & builder, solo
Client
Samira Kamara
Timeline
9 days, January 2026
Scope
Print · Web · RSVP
Live
valwedsfatie.com
Year
2026

One wedding, two ceremonies, nine days.

Samira came to me with what looked like one job. Design an invitation, put up a small page where people could RSVP. Nine days later it was a print invitation, a four-page site, two RSVP routes and a plan for the photos, all built for guests who would open it on a phone in Freetown.

The useful thing was not in the brief. There were two weddings. A traditional ceremony on February 1st in Hamilton, and the white wedding on April 4th at Hotel Cabenda. Same couple, different rooms, different guest lists, ten weeks apart.

What shipped is one site that carries both without pretending they are the same event.

In short

Both weddings have happened. The RSVPs landed in a sheet Samira read herself, and the printed QR still resolves today.

The phone stayed quiet after handover, which was the whole point.

The challenge

The brief said one wedding. The calendar said two.

The first list I got was four lines. People upload photos. People RSVP for the traditional wedding. Design the invitation for April 4th. Connect the site to a QR code. Read quickly, that is one project with four tasks. Read slowly, the second line and the third line are describing different weddings.

So I asked. February 1st, Hamilton, family and community. April 4th, Congo Cross, cocktails and a guest list. One RSVP form would have served both of them badly, and the people invited to only one of them worst of all.

Everything after that was governed by a date I could not move. The invitation had to be at the printer. Print does not get a hotfix.

  • Two ceremonies, ten weeks apart, one guest-facing brand
  • Guests in Freetown, on phones, on mobile data
  • A print deadline that fixed the order of every other task
  • One person, nine days, $250

The decisions.

01

Two ceremonies, two question sets

Context

The groom is Valentine on April's invitation and Idrissa on February's. Same man, two names, because two different rooms are being invited. One form would have forced those rooms into the same words. The traditional ceremony is a family occasion at a house on Murana Sesay Drive, where households arrive together and the room runs in more than one language. The white wedding is an afternoon at a hotel with a guest list and a caterer. The questions worth asking are not the same questions.

Options considered

  • One RSVP form with an event picker at the top (rejected)
  • Two forms, each written for its own room

The call

Two forms on two routes. The traditional one asked thirteen questions: relationship to the couple for seating protocol, whether you would take part in the gift presentation, transport, language preference, and it counted the RSVP by household rather than by head. The wedding one asked ten: dietary needs, song requests, plus-ones, and it confirmed against the physical invitation.

Evidence

They ran on Google Forms, which is the only reason they could be that specific on day nine. Thirteen questions cost an afternoon of writing rather than the week of building I did not have.

Outcome

The February form asked about the things February needed. Nobody answered a dietary question for a ceremony that was not catered.

02

The client had to read the answers without me

Context

Samira and the couple are not technical, and the wedding was going to happen whether or not I was reachable that week. Whatever collected the RSVPs had to be something they could open, sort and count on their own, months after I had stopped working on the project. That ruled out anything with a database and a login behind it.

Options considered

  • Custom backend with an admin dashboard I would maintain (rejected)
  • Embed the Google Form and accept the seam in the design (rejected)
  • Build the form on-brand, wire it into Google Form fields

The call

The form is the site's own. Same navy ground, same Baskerville labels, same glass panel as the invitation card. Behind it, every field is wired to a field on a Google Form, so each submission lands in a Google Sheet Samira already knew how to open. Accept and decline are two buttons rather than a dropdown, because that is the only question on the page anyone actually thinks about.

Evidence

Embedding the Google Form directly would have given her the same spreadsheet and cost the design: a navy panel with a white rectangle inside it, wearing Google's fields and Google's idea of a heading. Wiring it behind the form kept both.

Outcome

Guests never leave the invitation to answer. Samira could see everyone who had signed up without calling me. Nobody maintains a backend.

03

The photos page is a door, not a gallery

Context

“Guests upload photos and view a gallery” sounds like one feature. It is two products. Storage, moderation, and someone awake to run it during a reception I was not attending.

Options considered

  • Custom uploader on Drive's API, gallery rendered on the site (rejected)
  • Google Form with file upload (rejected)
  • Shared album, linked from a page in the site's own voice

The call

The photos page holds one button and one honest sentence about when the gallery opens. The upload itself happens somewhere guests already have an account and already trust with photos.

Outcome

Nothing to moderate, and nothing of mine to break in the middle of a party I was not at.

04

Domain before QR before print

Context

The QR code points at a domain. The domain has to exist before the code can be generated, the code before the artwork is final, and the artwork before anything is printed. After that the link is permanent, on paper, in someone's house.

Options considered

  • Print first with a placeholder and redirect later (rejected)
  • Buy the domain, generate the code, then close the artwork

The call

I bought the domain first, generated the code against it, tested it, then placed it in the invitation. Samira picked valwedsfatie.com over my shortlist. She was right that guests forget names and remember “the wedding site”.

Evidence

The panel prints the address in words directly above the code. That was the hedge: the QR is set in the invitation's own pink rather than black, which is a real contrast risk on a card someone scans in a dim room, and a guest who cannot scan it can still read it and type it.

Outcome

A printed link that still resolves today. This is the one dependency in the project where getting the order wrong costs a reprint rather than an afternoon.

05

Spend the interaction budget once

Context

A site like this easily ends up with something moving in every section. Each one costs a frame budget on a phone on mobile data, which is the only device that matters here.

Options considered

  • Reveal animations throughout (rejected)
  • One interaction, everything else still

The call

One canvas layer of water across the whole page that responds to touch, prompted by two words above the invitation card. Nothing else moves. The card, the event cards and the forms are all static.

Outcome

The one moving thing is the one people remember, and the page still reaches largest contentful paint in about two seconds on a throttled phone.

See it live — valwedsfatie.com

The results

Client:
Samira Kamara
Design and build:
Theodore Rogers
Stack:
Next.js on Vercel
Print:
Gatefold invitation, vellum inner card

Want outcomes like this?

Get in touch
9Days, brief to live
2Ceremonies, one site
2.1sLCP on throttled mobile

Reflection

Build for the person who runs it after you leave.

The constraint that shaped this project was not the nine days and it was not the budget. It was that I would not be there afterwards. The couple and the family are not technical, both ceremonies were going to happen on their dates, and the last thing anyone needed in the week of a wedding was a dependency on me answering a message.

So every systems decision came out the same way. The RSVPs land in a Google Sheet because Samira can open a spreadsheet and count her guests without calling me. The photos live in a shared album because a shared album cannot break in a way I would have to fix. The form looks like the invitation because that part is mine, and the plumbing is Google's because that part has to outlive the engagement.

None of that is the impressive answer. There is no database here and nothing worth a diagram. It is the correct answer, and I would make the same calls again for a client in Freetown planning two events ten weeks apart.

The work I still stand behind most is the reading of the brief. Four lines of requirements contained a second wedding that nobody had said out loud, and catching that on day one is worth more than every hour I spent on export settings.

[ Keep scrolling — next case ]

Lan 4 Vote