A panel for whoever is running the event, not for the agency that built it. Guest list with RSVP state, gift registry, a site editor the client actually operates, and a moderated message wall. Self-initiated and navigable — the answer to the request that always arrives two days before: change this here.
01 / THE PROBLEM
Every small change goes through the developer.
An event site is finished weeks before the event, and then it changes every day: a guest who cannot come, a gift already bought, the ceremony time that moved by half an hour. If each of those goes through whoever built the site, two things happen — the site goes stale, and the developer resents a project that was supposed to be closed.
I built this demo around the opposite premise: the person running the event edits it, and the build is done when they no longer need me.
02 / THE APPROACH
A countdown is a better home screen than a dashboard.
The panel opens on how many days are left, because that is the number the client actually thinks about. Under it sit the three things that move — confirmations, gifts and messages.
The site editor is the part that had to be gentle. It is not a page builder with a hundred options: it is the handful of fields that genuinely change, in the order they change. Constraining it is what makes it usable by someone who has never opened a CMS.
03 / THE BUILD
Guests, gifts, editor and a wall that needs moderating.
Guest list with real state. Confirmed, pending, declined — plus companions, which is where the head count usually breaks.
Gift registry. Each item has a state, so two people do not buy the same thing.
Message wall with moderation. Anything a guest writes in public needs an approval step. That is not a feature, it is a requirement, and skipping it is how a wall becomes a problem on the day.
The demo runs in the browser on fictional data. In production this is the flow I already shipped for real, with PIX and transactional email — this is its navigable version.
Screens
5
Editable site
yes
File
1 HTML
