A mobile app for coordinating group travel — designed from first principles 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 missed the updated plan. No one knows what's actually decided versus still being debated. One person absorbs all the coordination overhead, and when something changes, there's no reliable way to tell everyone.
The failure mode is consistent across extended family travel: the real problem isn't a lack of enthusiasm or ideas. It's the gap between shared intent and durable, shared coordination.
"The core failure is not communication. It is the absence of a shared, stable record of group intent."
I designed this product from observation and reasoning, not from field research. That shapes how I hold the assumptions — carefully, and with specific hypotheses about what would validate or kill them. The "what I'd validate" section below is the honest version of that.
The extended family trip concentrates every coordination failure this product is designed to address: multiple family units with different priorities, implicit generational hierarchies, and participants ranging from grandparents to toddlers.
The person who booked the Vrbo 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 product's primary value: a shared surface so they stop being the single point of failure.
Most travel apps think in two modes: full user and child. The extended family trip has a third — someone old enough to have real preferences and deserve to be heard, but who existing tools either ignore or treat like a small adult.
The participant tier is primarily about giving that person a genuine voice: they can see the full itinerary, propose ideas, vote, comment, and make personal commitments. The protection against coercion follows from that same respect — if you genuinely treat teenagers as participants, you also don't let other users assign them tasks. The coercion happens informally in real life. The app will not formalize or accelerate 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 — a completely different visual language, warmer and simpler, with descriptions written for a child rather than an adult. Nothing to manage.
The product has a lot of features, but three decisions shaped everything else. Each one started as a conviction, got stress-tested, and came out either confirmed or meaningfully refined.
Most collaboration tools treat disagreement as a problem to resolve. I treated it as a feature. If someone wants to do something different from the group, they fork the itinerary — a parallel plan, visible to everyone, operating alongside the main one. The main itinerary doesn't have to be a battleground. Forks are how the group handles the fact that not everyone wants the same thing, without anyone having to fight about it.
Forks are first-class objects: named, attributed, with their own itinerary items and committed flags. A fork can rejoin the main plan, or it can simply expire when the sub-group does their thing and comes back for dinner. A fork dying quietly is fine — the app is a coordination surface, not a tracker.
Stress-testing revealed two vulnerabilities. First, the original merge-to-main feature allowed any user to unilaterally fold a fork back into the main itinerary — which cuts against the product's no-hidden-authority principle. Resolution: merge either gets dropped or becomes a proposal (one member nominates, the group sees it, anyone can object). Second, the fork model originally had one visibility mode. Adding open vs. private forks — where a private fork shows its existence but not its contents or membership — extended the model to cover a different use case: separation without conflict, not just disagreement. Grandma and Grandpa's date night doesn't need to be a group itinerary item.
This was the decision I arrived at latest and feel most confident about. The original instinct was a task system where someone creates a task and claims it. The problem: if noticing a gap automatically makes you responsible for filling it, people stop noticing gaps. You create an incentive for silence, which is exactly the wrong outcome.
In Who Booked This?, the person who notices that the rental car needs to be returned is not the person who has to return it. Noticing and doing are two separate acts. The task sits unclaimed, visible to everyone. As the deadline approaches, it rises in the UI and sends a group notification — not pointed at any individual, surfaced to everyone. Someone volunteers or they don't. The app never assigns.
The no-coercion principle was designed for asymmetric relationships — the teenager being voluntold, the implicit power dynamics in extended family groups. But applying one rule to all relationship types creates friction in symmetric ones. A couple coordinating logistics is a different social context. If a wife has already agreed offline that her husband will return the car, making him open the app just to claim a task is unnecessary friction. The real question is whether most real-world task assignments are genuinely unilateral or just pre-agreed logistics. A consent-based assignment model — where the assignee gets a notification and can decline — might preserve the principle while reducing that friction. That's the hypothesis to test.
Child mode started as a planning restriction — children see a simplified view, nothing else. But there's a second problem most apps conflate with it: sometimes the adults are planning something the children shouldn't know about. A surprise. A budget conversation. Something that's simply not their business.
These are two distinct features. Child mode (access tier) restricts what a user can do. The adult-only flag (content visibility) controls what a user can see. Items with the flag don't appear as redacted in the child view — they simply don't exist. A child looking at the itinerary has no way of knowing something is hidden from them.
This product was designed from reasoning, not from watching real users. These are the places where my reasoning could be wrong — and what I'd look for to find out.
If noticing a gap doesn't create ownership, people will surface problems they'd otherwise stay silent about.
Social pressure reasserts itself anyway, or the group free-rides — everyone notices, nobody claims.
Ratio of tasks created to tasks claimed by the creator. If it's consistently high, decoupling isn't working behaviorally.
Time-to-claim on tasks. If unclaimed tasks regularly expire, either the group is disengaged or the incentive structure failed.
Participating adults (not organizer, not teens) surfacing tasks. They have full context and no structural barrier. Silence here is the real warning.
A consent-based assignment model — assign with a notification the assignee can decline — reduces friction without abandoning the principle.
Fork visibility means the group knows where everyone is, reducing confusion about divergent plans.
Visibility is theoretical if half the group has notifications muted or isn't checking the app regularly.
I drew a clear product boundary here: the app serves people who are using the app. Someone in the group is keeping the others in the loop — that's a social contract, not a product responsibility. What I'd actually measure is notification engagement as a leading indicator of whether fork visibility is functioning in practice.
Giving teenagers genuine agency — propose, comment, vote, fork — makes the app feel like it's for them, not just about them.
The tier is designed thoughtfully but teenagers still don't engage, either because the trip context doesn't motivate them or because the adults around them don't either.
Whether participant-tier members engage at all — propose, comment, or commit. Not whether they surface logistics gaps; that's not their job.
Participant accounts join but never interact. That suggests the tier is read-only in practice even if it's not read-only in design.
The standard metrics — downloads, session length, daily active users — 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.
High session length is not a goal. The app should be fast to check and easy to update. Fork proliferation is not a goal — a trip with ten open forks has probably fragmented rather than coordinated.
Four artifacts produced for this project, each covering a different layer of the product.