How We Built Real-Time Collaboration into a Seating Chart Tool (And What We Learned)

Here is a question that keeps event-tool builders up at night: what happens when two people drag the same table at the same time?

It sounds academic. It is not. If you are an event planner working on a floor plan with your venue coordinator, or a couple dividing up the seating chart on a Sunday evening, this is the exact moment your tool either works or breaks. One person moves Table 5 closer to the dance floor. The other reassigns a guest at Table 5 to Table 8. Both hit save. What does the chart look like now?

Most tools dodge this problem entirely. They give you single-user editing and a “share” button that exports a static PDF. Or they let multiple people open the chart, but the last person to save overwrites everyone else's work. We decided to solve it for real.

The Problem: Seating Charts Are a Team Sport

A seating chart is never a solo project. At minimum, two people have opinions about it. At a corporate gala, you have the event planner, the venue coordinator, and possibly a client who wants sign-off. At a wedding, you have the couple, maybe a parent or two, and the day-of coordinator who needs to know where the head table ends up.

The traditional workflow looks like this: one person creates the chart, exports a PDF, emails it to the next person, waits for feedback, makes changes, exports again. Three rounds of this and a week has gone by. If two people make changes to their own copies simultaneously, someone has to manually reconcile the differences. At 150 guests, that reconciliation is a full afternoon.

We wanted to eliminate all of this. The goal: two people open the same chart on different devices, and both can edit it simultaneously. Changes appear on the other screen in under a second. No exports, no version conflicts, no coordination overhead.

What “Real-Time” Actually Means

The phrase “real-time collaboration” gets thrown around loosely. Some tools mean “we auto-save every 30 seconds.” Others mean “you can see a cursor.” Here is what it means in SeatPlan.io:

This is the same kind of experience you get in Google Docs, but applied to a visual, spatial tool where people are dragging objects around a canvas rather than typing text. The engineering challenge is fundamentally different, and that is where the interesting decisions live.

The Hard Problem: What Happens When Edits Collide

Text is forgiving. If two people type in different paragraphs of the same document, merging is straightforward. A seating chart is spatial. Tables have x/y positions, guests have seat assignments, and moving one thing affects the logic of five others.

We evaluated three approaches before building:

CRDTs, Without the Computer Science Lecture

Think of a CRDT as a data structure with a built-in referee. Each user has their own copy of the seating chart. When you make a change, it is applied locally first—so you see it instantly, no waiting for the server—and then broadcast to everyone else. When a remote change arrives, the CRDT merges it into your local copy automatically.

The key property: it does not matter what order the changes arrive in. User A's change can arrive before or after User B's change, and the result is always the same. Both users always converge on the same state. This is called eventual consistency, and it is the same principle that powers Google Docs, Figma, and other collaborative tools.

We built this on top of Yjs, an open-source CRDT library. Our seating chart data—tables, guests, special areas, chair rows, and all their properties—lives in a Yjs document that synchronizes across all connected clients via WebSocket. The architecture is serverless: AWS Lambda handles the connection management, and the CRDT logic runs on each client. There is no central server deciding “who wins.” Every client is an equal participant.

How It Works in Practice: Sharing a Live Link

Technical architecture is only interesting if it translates to a workflow that saves you time. Here is what real-time collaboration actually looks like when you are using SeatPlan.io with a client or coordinator:

This replaces the PDF email chain entirely. Your coordinator can review the chart from a tablet during a site visit, move the head table to where it actually fits, and you see the change on your laptop at home in real time. One conversation, one chart, zero version confusion.

Permissions: Giving Your Client Access Without Giving Them the Keys

Real-time editing is powerful, but sometimes you do not want everyone to have the same level of control. A venue coordinator who is helping with layout should probably not be reassigning the bride's family to a different table. A client reviewing a corporate gala chart should be able to see everything but might only need to move a few specific elements.

SeatPlan.io's Event Manager tier supports two levels of permission control:

Permissions are enforced at the data level, not just the UI. A view-only collaborator cannot send edit commands to the server even if they tried. This matters if you are sharing charts with external parties—the access controls are real, not cosmetic.

Under the Hood: The Engineering Choices That Matter

You do not need to understand the engineering to use the tool. But if you are evaluating SeatPlan.io for a professional operation—or if you are a developer curious about how this works—here are the decisions that shaped the system.

What We Learned Building This

Building real-time collaboration into a spatial tool is genuinely hard. Here are the lessons that might be useful whether you are evaluating tools or building your own.

Two Collaboration Models: Couples and Professionals

We built two distinct collaboration experiences because couples and professional event planners have different needs:

Both tiers use the same underlying CRDT engine. The difference is in the permission model and the workflow surface. A couple does not need element locking or client access controls. A venue coordinator managing fifteen events per month does.

Frequently Asked Questions