Messy Tables · an operations platform for events

In one line: one file per event, shared by the planners, the couple and the guests. Built for a curated-events concierge in Mexico City and in production since September 2026.

The problem it solves

The planners ran each wedding from several spreadsheets: a payments control sheet, a checklist of 90 tasks, a comparison of venues and a list of hotels. Guests answered invitations in scattered messages. Every new event started from copy-and-paste.

The platform turns their own process, seven steps from first inquiry to the wedding day, into seven modules. It starts from their real spreadsheets, imported, so nothing is reinvented.

Who uses it

• Planners see every event: payments coming due, overdue tasks, RSVPs, vendors, and the reusable catalogs of venues, vendors, hotels and tasks.
• The couple sees only their event: progress, what comes next, their tasks, what they have paid and what is due, the venue, hotels and guest answers live. Everything is transparent, because the couple pays each vendor directly.
• Guests need no account. Each household gets a signed link to answer for each person and each sub-event, and to see the travel guide.

What it does

• Payments and checklist, with a background worker that sends reminders.
• Invitations and RSVP in English and Spanish, by email and QR, with a guest import from spreadsheets and an export.
• Venue comparison, quote and contract. The guest count recalculates the comparison, and the quote and the contract come out as PDFs.
• Scouting and travel: venue photos, availability, places and the guests' travel guide.
• The wedding day:
  • a minute-by-minute timeline, the vendor schedule and seating;
  • QR check-in for each sub-event, designed to keep working with the phone in airplane mode and to sync when the connection comes back;
  • a photo album by QR.
• The floor plan:
  • a scale plan of the room for each sub-event, with the planners designing and both planners and couple seating guests;
  • automatic seating with a preview, and undo;
  • metres or feet, and a PDF to scale for the venue.
• Sales:
  • a public landing page and a six-question brief («Tell us your vision») that creates a prospect and notifies the planners;
  • a sample event that prospects can walk through.
• Bilingual and bi-currency from day one: English and Spanish, MXN and USD. The platform records payments and reminds people about them; it never holds money.

How it's built

• Backend: Python and FastAPI with asyncpg on PostgreSQL 16, plus a background worker from the same image. Database migrations are plain SQL files, applied at start-up and never edited afterwards.
• Frontend: a PWA in React 19, Vite and TypeScript, with i18next for English and Spanish. It can be installed and is served by nginx.
• Sign-in: with Google, with roles. An account that was not invited gets a polite refusal, and no user is created. Guests use signed links instead of accounts.
• Containers: four, for the database, API, worker and web.
  • The database sits only on a private internal network.
  • The API and the worker reach it from inside.
  • Only the web and the API are published, through the reverse proxy.
• Backups and checks:
  • A backup script saves, lists, verifies and restores.
  • A verification script checks the live deployment end to end.
• How it was built:
  • Phase by phase, between September 23 and 27, 2026.
  • Each phase closed against acceptance criteria with real output from the client's imported data.
  • Several phases planned at 3 to 4 sessions were completed in one.

In numbers

Photos

These are public pages only. The inside of the app holds the client's real events, so it is not shown here. Opening the sample event needs a session, and these photos were taken without creating any data.

Worth pointing out

• Built from the client's real data, not from assumptions. Each module started by importing their own spreadsheets, and each phase was accepted against them.
• Three audiences, one source of truth. Planners, the couple and the guests see the same data through different doors, with access decided by role or by a signed link.