A guided tour of every screen
we've built so far.
Each section below opens with what the role is and why it exists, then walks through the screens in the order a real user would meet them. Click any tile. Every link works.
What you're looking at.
Kehitys is a whitelabel platform for invitation-based events: RSVPs, signed-token invitations, ticket entitlements, door scanning, post-event recaps. Every event runs as its own tenant on its own subdomain with its own brand.
The first real instance is Publicis Sweden's 100-year anniversary celebration. The screens on this demo are themed for that event so the visual language stays concrete, but the underlying system is generic. Any future client gets the same shells skinned to their brand.
Everything you'll click is mock data. The names are made up, no real emails are sent, RSVP forms don't actually submit, and the scanner stations won't consume real tickets. The visual flow, copy, layout, and navigation are exactly what the production system will look like. only the backend is short-circuited so the demo deploy is safe to share.
Six sections.
How the invitation reaches a guest.
Every guest journey starts in their inbox. A single-use signed token in the email URL lets them land on the brand without a password, decide if they're coming, and book what they need. This first arc covers the moment a save-the-date hits the mailbox through to the RSVP confirmation.
The happy path
Click forward through the six steps a real guest will follow. The link in step 1 is the same redirect a clicked email would trigger.
The save-the-date email
What lands in the mailbox. Plain HTML, no tracking pixels, one CTA.
Token landing
The CTA in the email points here. We verify the token, single-use-consume it, then redirect.
Save the date
Editorial hero. The guest's name, the date, two next actions.
RSVP: step 1
Yes / Decline / Decide later. No registration required.
RSVP: step 2
Allergies, accessibility needs, plus-one. Only shown if the answer is yes.
RSVP confirmed
Receipt with the calendar add, cancel link, and what to expect next.
What if the link breaks?
Email forwarding, expired tokens, and second devices all land on clear recovery surfaces.
Living with the invitation.
After RSVP the guest has a small home inside the platform: a personal invitation page, a notifications inbox, the things they own (modules, upgrades), and the controls the law requires us to give them.
Personal surface
Sparse by design. The platform never pretends to be a social network.
Your invitation page
Identity surface. Plus-one status, table number once assigned, day-of pass when it unlocks.
Notifications inbox
Chronological feed, category-tagged, deep-linked from emails.
Your tokens & access
Every entitlement scanned today, with timestamps and station names.
Day-of pass
Apple/Google Wallet-style page that doubles as the door QR.
Evening flow
What's happening right now, where the guest should be, what they still own.
Account
Email, language, name. The minimum legitimately needed to invite again.
Owned things
VIP upgrades and secret unlocks. A single token-grant flow that mints modules and reveals hidden sections on /me.
After the event + compliance
The screens GDPR requires us to expose to every data subject, plus the wrap-up surfaces that close out the event arc.
Gallery & recap
Post-event memory page. Photos, programme summary, thank-you note.
Privacy policy
What we collect, who we share with, how long we keep it. Per tenant, with subprocessor list.
Accessibility statement
WCAG 2.2 AA conformance, known issues, contact for accessibility requests.
Delete my data
Self-service GDPR Article 17 erasure. Triggers a Temporal workflow with operator review.
The event manager's workbench.
Each event has its own admin shell. Publicis is the first, and every future tenant gets the same set on their own subdomain. The admin owns guests, programme, tickets, communications, and the door. This section walks through every workbench an event manager touches.
Day-to-day operations
Communications
Door, bar, and stations
Physical-world surfaces. The scanner stations themselves run on token-authenticated URLs; the admin pages here configure them.
Governance
Authentication
Magic-link primary, TOTP 2FA mandatory for tenant staff. Click any of these to see the surfaces, even though they're normally only reached via the auth flow itself.
The agency portal.
Kehitys-the-company is an agency in the platform's terms. An agency owns multiple tenants. Publicis 100 is the first, and the same shell scales to every future client. This section is how an agency manages its book of business.
The agency workbench
The platform operator.
Kehitys itself runs the multi-tenant platform across every agency, every tenant, and every event. The super-admin shell is what platform engineering and platform compliance use to keep the lights on, meet legal obligations, and respond when something breaks.
Day-to-day platform operations
Governance and compliance
Regulator-facing surfaces. These exist because the platform processes personal data across multiple data controllers and has to evidence its posture continuously.
Public surfaces and design references.
A few screens don't belong to a specific role. The status page is public. The scanner stations run on operator devices but live on the same codebase. The design references show how the brand system composes.
Built on Next.js 16, Mantine v8, Postgres with row-level security, Temporal for durable workflows, and Specific.dev for the runtime. No icon libraries, no Tailwind. Typography and colour do the work.
This demo runs against mock fixtures. The same screens connect to the real database the moment the mock-mode flag flips off, tenant-by-tenant, as backend lands.