We’ve officially started development on GraceSoft RSVP — a mobile-first, real-time wedding operations dashboard built around Google Sheets synchronization.
The initial idea came from a simple real-world question:
“Is it possible to build a live dashboard connected to a Google Spreadsheet that updates automatically as the spreadsheet changes?”
The answer was yes — but rather than building a simple spreadsheet viewer, we decided to approach the problem like an operational platform.
The Vision
GraceSoft RSVP is designed to help:
- couples
- coordinators
- wedding helpers
…manage guest operations in real time.
The goal is to transform familiar spreadsheet workflows into a responsive, mobile-friendly operational dashboard experience.
Instead of requiring users to learn a custom admin panel, the spreadsheet itself becomes the content management system.
Users continue updating guest information in Google Sheets while the dashboard automatically reflects changes live.
Why Google Sheets?
One of the most interesting engineering aspects of this project is that the source dataset is intentionally flexible.
We may not always control:
- column naming
- column order
- optional fields
- spreadsheet formatting
This means the application cannot rely on hardcoded indexes or rigid schemas.
The dashboard has to adapt dynamically.
That led us toward building:
- dynamic header mapping
- normalization layers
- typed transformation pipelines
- resilient data parsing systems
rather than directly binding UI components to spreadsheet cells.
Core Architecture
The current planned architecture looks something like this:
Google Sheets
↓
Google Sheets API
↓
Normalization Layer
↓
Typed Guest Models
↓
Dashboard API
↓
Reactive Mobile UI
Rather than exposing the spreadsheet directly to the frontend, the server transforms raw spreadsheet data into structured internal models.
This gives us:
- schema flexibility
- safer parsing
- cleaner frontend architecture
- reusable analytics systems
- future scalability
Technical Goals
This project is also an opportunity to explore several frontend engineering concepts in a practical production-like environment.
Planned Technical Features
Dynamic Header Mapping
The dashboard should continue working even if spreadsheet columns change names or move positions.
Examples:
RSVP
RSVP Status
rsvp_status
Guest RSVP
All of these should map correctly.
This introduces:
- normalization utilities
- synonym matching
- defensive parsing strategies
Real-Time Updates
The dashboard should update automatically without refreshing the page.
The initial implementation will likely use polling with SWR refresh intervals.
Later phases may introduce:
- Server-Sent Events (SSE)
- streaming updates
- activity feeds
- reactive state synchronization
Typed Data Models
All spreadsheet data will eventually be transformed into typed models.
Example:
type Guest = {
id: string;
name: string;
side?: string;
pax?: number;
rsvpStatus?: string;
arrivalStatus?: string;
diet?: string;
table?: string;
};
This creates a clean separation between:
- external datasets
- application logic
- presentation layers
Mobile-First Operations UI
Wedding coordinators and helpers are likely to use the dashboard primarily on phones during live events.
The UI is therefore being designed mobile-first with:
- touch-friendly cards
- responsive layouts
- searchable guest lists
- real-time status indicators
- operational analytics
Planned Dashboard Views
Operations Dashboard
A high-level overview screen showing:
- total guests
- confirmed RSVPs
- arrivals
- dietary analytics
- live activity updates
Arrival View
A view-only operational guest list showing:
- guests who have arrived
- side allocation
- dietary restrictions
- table information
This screen is intended for:
- coordinators
- helpers
- ushers
- logistics support
Nice-to-Have Features
Some planned experimental features include:
- QR-based guest check-in
- passcode-protected dashboards
- activity logs
- live synchronization streams
- operational analytics
Current Tech Stack
Current planned stack:
- Next.js 15
- TypeScript
- Tailwind CSS
- shadcn/ui
- Recharts
- Google Sheets API
- SWR
- Zod
Hosting will likely be handled through Vercel.
Security & API Design
One important engineering decision is that the raw spreadsheet will never be exposed publicly.
The application uses:
- server-side Google Sheets fetching
- readonly service account permissions
- internal normalization pipelines
- environment-based credential management
The spreadsheet behaves like a backend CMS, while the frontend remains a structured operational interface.
Why This Project Is Interesting
What started as a wedding helper tool quickly evolved into something broader:
a lightweight real-time event operations platform.
The underlying architecture could eventually support:
- conferences
- ministry events
- church attendance systems
- volunteer operations
- registration workflows
- hospitality coordination
Next Steps
Current milestones include:
- setting up Google Sheets synchronization
- building normalization utilities
- implementing typed guest models
- creating responsive dashboard layouts
- implementing real-time polling updates
- designing reusable analytics components
We’ll continue documenting the development process publicly as the project evolves.
More updates soon 👀
Top comments (0)