MeshiMatch

Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for MeshiMatch

Inspiration

Choosing where to eat is a small problem that repeatedly wastes time and creates social friction. In many groups, the loudest preference wins while quieter people say “anything is fine,” even when they have a real constraint. Existing polls collect answers, but they rarely make the group feel more connected.

We asked a different question: what if deciding felt like gathering? Research on joint attention, coordinated action, shared goals, mutual dependence, and synchronized outcomes suggested that online closeness comes from acting in the same space toward one visible result—not simply from seeing the same content.

What it does

MeshiMatch supports two moments.

For future plans, the home is a Dining Plaza. Every picnic table on the lawn represents a real upcoming meal. People approach a table, take a seat, and continue planning with the group.

For people who are already together, Eat now creates a live table in seconds. Friends join by QR or room code, and the host participates too. Each person privately throws one Wish and one optional Avoid onto the table—for example, “something warm,” “plates to share,” or “not spicy today.” MeshiMatch combines the signals and important constraints into one nearby restaurant. The group gets one anonymous objection window, then the same dinner ticket arrives on every phone.

The result is quick, fast, and fun: less negotiation, more movement, and a fairer way to include preferences that are hard to say out loud.

How we built it

The product is built with Next.js 16, React 19, TypeScript, Supabase-compatible persistence, a local JSON demo database, QR joining, and a custom restaurant ranking pipeline.

Codex and GPT-5.6 were used across the full build loop:

• synthesized research on what makes online interaction feel close and gathered;
• translated the findings into interaction flows and two distinct modes;
• implemented the Dining Plaza, instant-room APIs, multi-device synchronization, QR/code joining, Wish/Avoid inputs, ranking, anonymous objections, and shared ticket delivery;
• generated and refined the garden and table visual assets, then integrated them into the working UI;
• tested the room flow in a real browser and validated it with Vitest, TypeScript, ESLint, diff checks, and a production build.

Challenges we ran into

The hardest design problem was balancing speed with psychological safety. A full questionnaire is too heavy when friends are already standing together, while open discussion can silence unpopular needs. We reduced the interaction to one Wish and one optional Avoid, kept the objection private, and limited the flow to one collective answer.

The hardest technical problem was synchronizing arrivals, responses, proposal timing, objections, and the final ticket across multiple devices without turning the host into a non-playing controller. The shared room state and polling API were designed so every phone remains a participant.

Accomplishments that we're proud of

• A coherent product experience rather than a disconnected recommendation form.
• Two modes that respect the very different UX of planning later versus deciding now.
• A hostless-feeling shared table where every participant gets a character and a seat.
• Private preference expression with one visible collective outcome.
• A working, testable multi-device flow from QR join to shared dinner ticket.

What we learned

Shared presence is not mainly about 3D graphics. It comes from visible co-presence, coordinated action, mutual dependence, and an outcome that arrives for everyone at the same time. The strongest interaction was not the individual recommendation card—it was the moment the same ticket landed on every phone.

What's next for MeshiMatch

Next we would connect the instant table to a production restaurant catalog and live opening-hours data, add movement and expressive avatar reactions, measure time-to-decision and preference inclusion, and test the flow with larger real-world groups where people are least comfortable voicing constraints.

Built With

• codex