GraceSoftGraceSoft

Starting Development on GraceSoft RSVP

Davina LeongMay 15, 20263 min read

We’ve officially started development on GraceSoft RSVP, a mobile-first, real-time wedding operations dashboard built around syncing with Google Sheets.

The 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 build a simple spreadsheet viewer, we decided to approach the problem as an operational platform.

The vision

GraceSoft RSVP helps couples, coordinators and wedding helpers manage guest operations in real time.

The goal is to turn familiar spreadsheet workflows into a responsive, mobile-friendly dashboard. Instead of asking people to learn a custom admin panel, we let the spreadsheet itself be the content management system. Users keep updating guest information in Google Sheets, and the dashboard reflects the changes live.

Why Google Sheets?

One of the most interesting engineering aspects of this project is that the source data is intentionally flexible. We may not always control:

  • column naming
  • column order
  • optional fields
  • spreadsheet formatting

So the application can’t rely on hardcoded indexes or rigid schemas. The dashboard has to adapt. Rather than binding UI components directly to spreadsheet cells, that led us toward building:

  • dynamic header mapping
  • normalisation layers
  • typed transformation pipelines
  • resilient data parsing

Core architecture

Google Sheets
↓
Google Sheets API
↓
Normalisation Layer
↓
Typed Guest Models
↓
Dashboard API
↓
Reactive Mobile UI

Instead of exposing the spreadsheet directly to the frontend, the server turns raw spreadsheet data into structured internal models. That gives us schema flexibility, safer parsing, a cleaner frontend architecture, reusable analytics and room to scale.

Technical goals

Dynamic header mapping

The dashboard should keep working even if spreadsheet columns are renamed or moved. All of these should map correctly:

RSVP
RSVP Status
rsvp_status
Guest RSVP

This calls for normalisation utilities, synonym matching and defensive parsing.

Real-time updates

The dashboard should update without a page refresh. The first version will likely poll using SWR refresh intervals. Later phases may introduce Server-Sent Events (SSE), streaming updates, activity feeds and reactive state syncing.

Typed data models

All spreadsheet data will be transformed into typed models:

type Guest = {
  id: string;
  name: string;
  side?: string;
  pax?: number;
  rsvpStatus?: string;
  arrivalStatus?: string;
  diet?: string;
  table?: string;
};

This keeps external datasets, application logic and presentation layers cleanly separated.

Mobile-first operations UI

Coordinators and helpers will mostly use the dashboard on their phones during live events. So the UI is designed mobile-first, with touch-friendly cards, responsive layouts, searchable guest lists, real-time status indicators and operational analytics.

Planned dashboard views

Operations dashboard. A high-level overview showing total guests, confirmed RSVPs, arrivals, dietary analytics and live activity updates.

Arrival view. A view-only guest list showing who has arrived, which side they’re on, dietary restrictions and table information. It’s built for coordinators, helpers, ushers and logistics support.

Nice-to-have features

  • QR-based guest check-in
  • Passcode-protected dashboards
  • Activity logs
  • Live sync streams
  • Operational analytics

Tech stack

  • Next.js 15
  • TypeScript
  • Tailwind CSS
  • shadcn/ui
  • Recharts
  • Google Sheets API
  • SWR
  • Zod

Hosting will likely be on Vercel.

Security and API design

The raw spreadsheet will never be exposed publicly. The application uses:

  • server-side fetching from Google Sheets
  • a service account with read-only permissions
  • internal normalisation pipelines
  • credentials managed through environment variables

The spreadsheet acts as a backend CMS, while the frontend stays a structured operational interface.

Beyond weddings

What started as a wedding helper tool quickly grew into something broader: a lightweight platform for running real-time events. The same architecture could eventually support conferences, ministry events, church attendance, volunteer operations, registration workflows and hospitality coordination.

Next steps

  • Set up syncing with Google Sheets
  • Build normalisation utilities
  • Implement typed guest models
  • Create responsive dashboard layouts
  • Implement real-time updates through polling
  • Design reusable analytics components

We’ll keep documenting the process publicly as the project evolves.

Originally published on DEV.

Share this post

← Back to Blog