A mobile app for coordinating group travel — designed for the extended family trip.
Group trips fail not because people don't care, but because information lives in a dozen different text threads. Someone always misses the updated plan. No one knows what's actually decided versus still being debated.
This is a pattern observed repeatedly across group travel: the real failure mode isn't lack of enthusiasm or ideas — it's the gap between shared intent and durable, shared coordination.
Specific failure patterns: plans communicated informally and forgotten; one person becoming the de facto coordinator absorbing all the labor; decisions made in side conversations never reaching the full group; no reliable way to notify everyone when details change; no agreement on what's decided versus still proposed.
The core failure is not communication. It is the absence of a shared, stable record of group intent.
The primary context is the extended family trip — a reunion, a vacation rental, a destination celebration. These trips concentrate every coordination failure the app is designed to address: multiple family units with different budgets and priorities, implicit generational hierarchies, and participants ranging from grandparents to toddlers.
This context also introduces the app's most important design constraint: the presence of teenagers. Teenagers on family trips occupy an awkward middle position — old enough to be socially pressured into responsibility, but young enough to be excluded from actual planning decisions. Who Booked This? treats this as a trust risk, not an edge case.
The person who booked the Vrbo, built the group chat, and is currently holding the entire itinerary in their head. Takes initiative on logistics, absorbs all coordination overhead, and has no structural support for any of it. The app's primary value proposition is giving this person a shared surface so they stop being the single point of failure.
Other adults in the group — other parents, partners, grandparents, aunts and uncles. Varying levels of engagement: some are highly opinionated, some are just showing up. May have strong preferences about specific things while being entirely disengaged from everything else. Needs low-friction access to the plan and the ability to register preferences without being expected to manage anything.
Not a child, not an adult. Has real preferences and deserves to know the plan. Should not be assigned tasks by the app under any circumstances — the coercion happens informally in real life; the app will not formalize or accelerate it. Sees the full itinerary and can propose or comment, but can only take on tasks through explicit personal commitment, never through assignment.
Participant-tier members cannot be assigned tasks by anyone through the app. Their commitment is always self-declared. Full-access members may assign tasks to each other — that is coordination. Assigning tasks to teenagers is coercion, and the app will not enable it.
Needs to know what's happening each day. Has no planning responsibility and no interest in logistics debates. Child mode provides a read-only, day-by-day view of finalized plans — nothing else.
The group itinerary is a shared, editable document — not owned by any single user. Anyone in the group can propose, edit, or remove items. There is no designated coordinator with special authority. This maps to how trips actually evolve: chaotic early on, converging as the date approaches.
Every edit to the itinerary is logged with the author, timestamp, and previous value. The audit trail serves two purposes: accountability (edits are attributed, creating natural social friction against bad-faith changes) and memory ("when did we decide that?" is a question that kills group trips — the trail is the receipts). Items are never deleted — they are archived. The record is always recoverable.
Every item on the itinerary exists in one of five states, visible to the full group.
| State | Meaning | Who sets it |
|---|---|---|
| Proposed | A user has floated an idea. Visible to all, no action required. | Any user |
| Active | The group is operating on this plan. Edits notify all participants. | Any user |
| Committed | A user has booked or confirmed this. Flags change attempts; informational only. | Self-declared |
| Forked | A sub-group is doing something different. Visible alongside main itinerary. | Any user |
| Archived | Removed from the active itinerary. Preserved in audit trail, not deleted. | Any user |
Forks are first-class objects. When a participant or sub-group wants to do something different from the main itinerary, they create a fork — a parallel plan visible alongside the group plan. Forks prevent the main itinerary from becoming a battleground and make divergence visible and legible rather than a confusing side-thread. Forks can rejoin the main itinerary or be promoted to it if the group converges.
There is no minimum threshold for a proposal to become Active. Any member can promote any proposal at any time. The check on unilateral action is not a gate — it is the fork. If someone promotes a plan the group dislikes, the group routes around it by forking.
Requiring consensus to advance a proposal creates the same bottleneck the app is designed to dissolve. Low friction to promote; low friction to diverge.
A task is a named coordination gap — something that needs to happen for the trip to succeed but hasn't been claimed. Tasks are distinct from itinerary items: they represent logistical requirements, not planned activities.
Tasks have three key properties: creator (the person who noticed the gap — creating a task confers no obligation to complete it); owner (whoever is responsible — full-access members can self-claim or assign to another full-access member; participant-tier members can only self-claim); and deadline tied to a real-world constraint.
As a task's deadline approaches, its visibility increases and triggers a group notification — surfaced to everyone, directed at no one. The social pressure to act exists in the room; the app does not manufacture or direct it.
Decoupling observation from obligation is essential. If noticing a gap creates ownership, people stop noticing gaps. The app rewards surfacing problems, not punishes it.
When a user has acted on a plan item in the real world — booked a hotel, purchased a ticket — they mark it as Committed. Committed is self-declared and purely informational. The flag warns the group before they change something, explains divergence after a change, and creates a visible record if anyone feels blindsided later.
Committed status does not lock an item or prevent changes. It makes the stakes of a change visible so the group can make informed decisions.
Anyone can view anything. Every edit is attributed and notified. Archiving requires confirmation; nothing is permanently removed.
Participant-tier members — teenagers — cannot be assigned tasks by anyone through the app. Their commitment is always self-declared. Full-access members may assign tasks to each other, reflecting agreements made outside the app — that is coordination, not coercion.
The system surfaces coordination information — committed flags, fork visibility, unresolved proposals — rather than forcing resolution. Social accountability does the governance work.
Disagreement about the plan is resolved by forking, not by fighting over a single itinerary. The main itinerary stays clean; divergence is legible rather than suppressed.
All participants have equal edit rights. The trip creator has only one additional power: removing members. The system does not privilege any user's edits over another's.
Proposing something and having acted on it are different states with different implications. The system keeps them separate and makes both visible.
Who Booked This? does not eliminate the social complexity of group travel. It makes coordination failures visible, traceable, and not silently absorbed by one person.
Who Booked This? uses per-trip pricing. The person who creates the trip pays a one-time fee to open it. All other members join and participate for free.
The trip creator is already the person with the most skin in the game. They initiated the coordination, they're holding the itinerary in their head, and they have the clearest incentive to solve the problem. Asking them to front the cost of the tool is coherent with their existing role.
It avoids the integrity problem of selling the app to individual users. A participant who just wants to see the plan and mark one committed item shouldn't have to buy software to do that. The creator subsidizes access for the group — which is, again, how the trip already works.
It scales naturally with usage. Someone who organizes one trip a year pays once. Someone who organizes five pays five times. There is no subscription to forget about or cancel.
Advertising and data monetization were rejected outright. Who Booked This? is a trusted shared space for family coordination. Introducing ads or third-party data access would contradict the product's core promise. The pricing model should be as legible and trustworthy as the app itself.
The standard metrics — downloads, daily active users, session length — measure reach, not whether the app is doing its actual job. The job is reducing coordination failures and keeping the whole group oriented around a shared plan.
The single most important signal: is the organizer the only person making edits? If the wiki is being treated as one person's document rather than a shared surface, the core premise hasn't landed.
After the trip, does anyone remember who booked what — and does the answer match what the app says? If the audit trail is accurate and the committed flags are trustworthy, the product worked.
High session length is not a goal. The app should be fast to check and easy to update. High notification volume is not a goal. Fork proliferation is not a goal — a trip with ten open forks has probably fragmented rather than coordinated.