Coordinating a 100-family wedding in real time — the Mangalam platform

A hundred-plus families, one date, and no second attempt

A large wedding is a logistics operation disguised as a celebration. This one had more than a hundred families to coordinate — each with its own travel plans, its own headcount, its own version of the schedule. The information lived where it always lives: phone calls, forwarded messages, and a dozen group chats with overlapping membership and no source of truth.

The failure mode is predictable. Schedules change, and some fraction of the crowd is operating on the old one. RSVP counts drift, and the people planning food and seating are working from numbers that were true last week. Every correction costs another round of calls. Multiply by a hundred families and coordination becomes a full-time job for several people — performed against a deadline that cannot move. A wedding ships exactly once. There is no patch release.

Why I rented the backend instead of building one

I built this at Xccessor, and the context shaped every decision: bootstrapped, which means every week of engineering was priced in runway. The question for each choice wasn't "what's the best architecture?" It was "what gets a working, trustworthy product in front of a hundred families fastest, without buying an ops burden nobody will carry afterward?"

Three options were on the table. Build a custom backend — an API server, a database, a sync layer to push live updates — which would have cost weeks before the first feature existed, plus servers to babysit on the event's most important day. Lean on generic shared tools — spreadsheets and group chats — which were the failing status quo, not a solution. Or build the product on a managed platform that already does the hardest part.

Option	Time to first feature	Real-time sync	Event-day ops	Runway cost	Verdict
Build custom backend	Weeks	Hand-roll	Servers to babysit	High	Overbuilt for the deadline
Spreadsheets + group chats	Status quo	None	n/a	—	The failing status quo
Managed platform (Firebase)	Days	Default	None	Low	Chosen — buy the hard part

The hardest part, specifically, was real-time sync. The product's whole reason to exist was: when something changes, everyone sees the change, immediately and identically. That isn't a feature you bolt on. It's the product. It's also famously fiddly infrastructure to hand-roll well — connections, reconnections, consistency across hundreds of devices of wildly varying quality.

That pointed at Firebase: a managed backend where real-time sync is the default behavior, not an achievement. Data changes, every connected client updates — no sync engine for me to write, debug, or operate. Cloud Functions covered the server-side logic that shouldn't run on someone's phone. The frontend was React — fast to build with, an ecosystem of already-solved problems, and a component model that fits a product that is essentially a set of live-updating views. The bet, plainly: buy the infrastructure, spend the runway on the product.

One guest list, one schedule, updating under everyone's thumb

What the families got was a single place where the wedding lived:

• A dynamic guest list built around how invitations actually work at this scale — families, not individuals, as the unit — with headcounts that change as travel plans firm up.
• RSVP tracking that updated totals the moment a family responded, so the people making real commitments — food, seating, transport — were always working from current numbers.
• The event schedule in one canonical version. When a time shifted, it shifted for everyone at once. No "which forward is the latest" archaeology.
• A live event feed for everything that doesn't fit in a table: announcements, changes, the running pulse of the event itself.

The texture of it in use is the point. An aunt updates her family's count from her phone; the organizer's total is already correct. A ceremony moves by an hour; the schedule everyone is looking at is already the new one, and the feed says why. Nobody chases. Nobody reconciles. The coordination work that used to be phone calls became ambient.

The planning got quieter — which was the goal

The honest outcome of a tool like this is invisibility. Communication and coordination got dramatically simpler: one source of truth instead of a dozen partial ones, and a planning process running on current information instead of stale copies. The software receded and the event came forward. For coordination software, disappearing is what winning looks like.

If you're coordinating a crowd on a deadline and a budget

The wedding is incidental. The shape — many parties, fast-changing shared state, a hard deadline, limited money — shows up constantly. What transfers:

Constraint	The move it forces	What it bought here
One capability is the product	Buy everything around it	Real-time sync, rented — weeks of infra became days of product
Bootstrapped budget	Price decisions in runway, not elegance	Skipped the "proper" backend that was better on paper, worse everywhere else
Immovable deadline	Shift the risk math toward boring	Managed services over clever infra you'd debug on the day
Real social unit ≠ a row	Model families, not individuals	Correct totals — the domain model beat any technical choice

If you're staring at a version of this — a crowd to coordinate, shared state that won't hold still, and a budget that punishes overbuilding — these trade-offs are the conversation worth having early. It's one I'm glad to have.