RSVP

Planning a trip with a group produces a predictable sprawl. The idea appears in one thread. Flight options go to another. Someone starts a spreadsheet for costs, a third thread collects accommodation links, and a fourth opens when someone drops out and everyone needs updating. Nobody holds a single view of what is confirmed, what is proposed, and what is still being argued about.

Existing tools each cover a slice. Booking platforms handle an individual itinerary. Notes apps handle lists. Chat handles the conversation, badly, because a decision made on Tuesday is buried by Thursday. Nothing handled the collaborative planning process itself: who is in, what is decided, what is still open.

RSVP was built to consolidate that coordination into one place, launching in New York. The premise was simple. Group travel was underserved not because the trips were complicated but because the deciding was, and the deciding had no home.

The constraint that governs most consumer apps applied here with force. A user who creates a group, invites friends and gets nothing useful out of the first planning session will not come back, and neither will the friends. The core flow, create a trip, add details, invite members, track decisions, had to work well enough in session one that the group chose it over the chat thread they already had open.

That shaped the build in specific ways. The invitation flow had to be close to frictionless. The collaborative interface had to make sense without explanation. And the structure for organising a trip had to match how groups actually plan, which is by topic, flights, accommodation, activities, rather than by date.

The competition was not another app. It was WhatsApp, which costs nothing to keep using. Every extra step in RSVP's onboarding was measured against that.

A trip plan is organised into sections: who is going, where and when, accommodation options under consideration, transport, and activities. Every section is collaborative. Any member can add an option, and members vote on or comment against specific proposals, so the discussion attaches to the thing being discussed rather than floating in a general thread.

Confirmed decisions are marked separately from proposals. At a glance, the group sees what is settled and what still needs a call. Because the plan is shared and kept in sync, a change one member makes is what every other member sees the next time they look; there is no version of the plan that lives only on one phone. Members who join late read the full history of what was discussed and decided without asking anyone to recap.

Invitations are a shareable link. The invitee lands in the trip plan immediately and creates an account from inside it, rather than being asked to sign up before seeing anything. That single decision made a significant difference to group adoption.

A timeline, everything in chronological order, is the obvious structure for a travel itinerary, and it is the one most tools reach for. It works for a confirmed trip. It fails during planning, when flights are not booked, accommodation is still being compared, and the dates themselves might be the open question. A timeline needs dates to hang things on; the planning stage is the process of finding those dates.

Organising by topic reflects the actual order of group decisions: agree where and who first, then narrow accommodation and transport in parallel, then fill in activities once the big decisions are settled. Each section can be at a different stage of settled without the whole plan looking broken.

The rejected alternative was to build both views and let users switch. That would have doubled the surface area of the first session, the one that had to be effortless. The timeline becomes useful after planning is done. The topic view is useful while it is happening, and that is when the app has to earn its place.

Someone creates the trip, names it, adds the rough where and when, and sends the link. Friends open it on their phones, see a plan already taking shape, and join. Over the following days, options accumulate in the sections: a couple of flight times, a few places to stay, a list of things people want to do.

Voting narrows each section. When the group settles on something, it is marked confirmed and moves out of the open pile. The person who normally does the chasing no longer writes the summary message; the plan is the summary. Someone who drops out or joins late does not trigger a re-explanation, because the state of the trip is visible rather than remembered.

The chat still happens. What changes is that decisions stop living in it.

A group creates a trip plan, invites members by link and runs the planning conversation inside the app rather than across multiple threads. Confirmed decisions are visible separately from open proposals. Members who join mid-planning catch up without a recap.

The coordination still requires the same conversations. The difference is that they now happen against a shared record of what was proposed, what was chosen and who is in, which is the part no chat thread ever kept.