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.

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:

• Find the one capability that is the product, and buy everything around it. Here it was real-time sync. Renting it from a managed platform turned weeks of infrastructure into days of product work.
• Price decisions in runway, not elegance. A bootstrapped budget is a forcing function. The "proper" custom backend would have been better on paper and worse in every way that mattered.
• An immovable deadline changes your risk math. When there is no second attempt, boring managed services beat clever infrastructure you'd be debugging on the day itself.
• Model the real social unit. The guest list worked because it tracked families, not rows of individuals. Getting the domain model right did more than 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.