Building a Wedding App for My Own Wedding
25 March 2026
In August 2026, Rosemarie and I are getting married. At some point, instead of setting up a wedding website like a normal person, I decided to build a native app.
I'm not entirely sure why. Probably because I couldn't help it.
What it is
ReD Sposi — Rosemarie e Daniele Sposi — is a full-stack wedding app available on iOS and Android. Guests log in with an invite code, and from there they get everything they need for the day:
- A countdown to the wedding
- RSVP with meal preferences, dietary restrictions, and shuttle requests
- The day's schedule, venue details, and recommended hotels
- A photo and video gallery — guests can upload multiple files at once with a progress bar, swipe through them, and skip. Videos are transcoded to MP4 server-side; thumbnails are generated with Sharp for both photos and videos and served via CloudFront
- A chat between guests
- A betting game — who cries first, how long the speeches run, that sort of thing
It's probably more app than a wedding strictly needs. But it was genuinely fun to build, and it gave me an excuse to think carefully about things I usually design for clients.
The stack
It's a monorepo: Expo + React Native on mobile, Express + MongoDB on the backend, a React + Vite admin panel, and a Next.js landing page. The mobile app uses NativeWind (Tailwind CSS for React Native), Expo Router for file-based navigation, and JWT auth with invite codes.
Nothing exotic. The same stack I've been shipping on for years — which is partly the point. This was a project I wanted to enjoy, not one I wanted to spend debugging an unfamiliar runtime.
Deploy is manual on a Ubuntu server via PM2. No containers, no orchestration. Fast to set up, easy to reason about, and more than enough for a few hundred guests.
Building something personal
Most of what I build is for other people — clients, users, businesses. This was different. Every decision I made, I made as both the developer and a user of the thing. That's a strange position to be in.
It meant I cared about details I might have skipped otherwise. The betting game leaderboard. The way the RSVP confirmation feels. The loading state on the chat. Nobody asked for these things. I wanted them.
It also meant the deadline was immovable and the stakes were personal in a way professional projects rarely are. There's something clarifying about building software where you genuinely can't postpone the launch date.
What's still to come
The app is live and guests are already using it. The chat runs on Socket.IO and push notifications are live. At this point, it mostly just needs people at the wedding.
The core loop works. Guests are booking, RSVP-ing, uploading photos, and placing bets.
August can't come soon enough.