The product doesn't help you book a trip, coordinate a trip, or remember a trip. It is the trip

That sentence came out of a working session with the startup's cofounders — the difference between building a better booking tool and building something that holds a trip as a stateful thing with memory, from a half-formed idea to a shared photo album months later.

01 • Context & Problem

Tab graveyards in a transaction-first world

Travel planning creates "tab graveyards." One person ends up holding together a dozen open tabs and tools — flights, a spreadsheet, a group chat, three booking sites — and everyone else just hopes it holds.

This was a real early-stage travel startup. I came in through a Lead Designer screening and used it as a live design exercise with the cofounders — thinking through the actual product problem in front of the people who'd have to live with the answer. Their feature list (AI concierge, bundles, global scope, curated suggestions, booking trust, temporal planning) became an architecture check, not a brief: does what I'm proposing actually house these, or am I inventing a product they don't need?

Category	What they optimize for
Kayak / Expedia	Transaction completion
Airbnb	Discovery + booking
TripAdvisor	Reviews + inspiration
The gap	No platform treats a trip as a persistent, stateful object

Existing travel tools optimize for transactions. None of them hold a trip as something with memory — from a half-formed idea to a shared photo album months later.

Three structural gaps made this worth solving:

02 • My Role

Scope I set myself, founder-level collaboration

Nobody handed me a scoped problem. I set the scope myself, across several conversations, and the first move I made was a boundary rather than a solution: separate the object (what a trip actually is) from the interaction (how people touch it) from the AI layer (how it participates) — and refuse to let any of them get solved out of order. When discussion drifted early toward AI behavior, I pulled it back to finish defining the object model first. That sequencing wasn't process hygiene — it was a bet that you can't say anything trustworthy about how people interact with a trip, or how AI should behave inside it, until you know what a trip is.

I also ran my own competitive teardown before proposing anything — Kayak, Expedia, Airbnb, TripAdvisor, Travala — split into booking/transaction platforms versus discovery/review platforms, specifically to isolate what none of them do: treat a trip as a persistent, stateful thing rather than a transaction sequence. That's where the differentiator came from.

Collaborators: Cofounders

03 • Design Challenges

Four tensions in one data model

Representation at any stage

A dream trip with no dates and a fully locked itinerary must live in the same model.

Not two different data models bolted together later. The system had to represent trips at any stage of completeness — from a half-formed idea to a locked itinerary — without forcing users into a different mode as the trip matured.

Logistics vs experience

Neither could silently override the other in the UI or in what the AI paid attention to.

Logistics are structurally load-bearing but invisible until they break. Experiences are emotionally load-bearing and the actual reason the trip exists. Weighting both correctly was a product architecture problem, not just a layout one.

Social configurations

Three friends splitting a beach house and an executive whose assistant builds 100% of the trip are both real users.

The system couldn't over-engineer a permissions model nobody asked for, or flatten real differences in trust and power between people on a trip. Different social contexts needed different modes without a one-size-fits-all gatekeeper.

AI lifecycle

A trip lives for months before it happens. AI needed to participate across that whole span.

Without nagging — manufactured anxiety that makes planning feel worse — or going inert — a chatbot you have to remember to summon. AI behavior had to shift meaningfully across a multi-month lifecycle, not stay fixed as a bolted-on persona.

04 • Key Decisions

Six decisions that defined the system

Object model

I rejected a single trip-level status flag in favor of composite, component-level state: Who / Where / When / What (Logistics + Experiences), with a linear lifecycle at the trip level but reversible state at the component level.

A single state machine for the whole trip was simpler, but couldn't represent the actual reality that a flight can be locked while dinner reservations are still fluid.

Lifecycle stage	What it means
Dream	Half-formed idea, no dates required
Plan	Structure emerging, components fluid
Build	Logistics locking, experiences shaping
Live	Trip in progress
Remembered	Shared memory, photo album

Signal source	Included in health?
Confirmed logistics	Yes
Must-attend experiences (flagged)	Yes
Fluid or optional plans	No
General content feed	No — separate layer

Health signal

I rejected folding "trip health" into the general content feed. Instead it's a separate layer, built only from confirmed logistics plus experiences the user has manually flagged as must-attend.

Deliberately excluding fluid or optional plans so the indicator doesn't get noisy or paternalistic about how someone should be traveling.

Permissions

I rejected a universal approval system where a single Coordinator gates every change — it creates an uncomfortable power imbalance among people who are actually social equals.

Instead, the trip's social context picks the mode at creation. The product doesn't decide the power structure; the group does.

Mode	Who holds power
Collaborative	Equal peers, shared building
Coordinated	One organizer, others contribute
Managed	Builder acts on behalf of traveler

Dream-to-Plan transition

I rejected hard-blocking unrealistic plans — three countries in five days gets refused outright — in favor of a two-beat soft nudge: validate the ambition, name the real constraint, then let the user push through anyway with a visible unresolved flag rather than a wall.

The product shouldn't refuse dreams. It should make constraints visible so users can decide whether to adjust or proceed with eyes open.

Traveler entry

I rejected giving every invited traveler full building access "to keep things simple." Instead, invited travelers get a curated, read-and-follow view — low-stakes edits are self-serve, structural changes route back to whoever built the trip.

Not everyone invited to a trip needs to be a planner. The entry experience should match the role they're actually playing.

Edit type	Invited traveler
View itinerary	Self-serve
Low-stakes edits	Self-serve
Structural changes	Routes to trip builder

Lifecycle state	AI behavior
Dream / Plan	Exploratory, low initiative
Build	Proactive on logistics gaps
Live	Timely, contextual alerts
Remembered	Quiet, archival assistance

AI's authority

I rejected a concierge-style AI that recommends or decides on the user's behalf, in favor of a strict assistance-only role. AI never introduces its own judgment — its behavior (timing, level of initiative) shifts by lifecycle state rather than being a fixed persona bolted on top.

The AI participates in the trip; it doesn't run it. Authority stays with the people who own the experience.

05 • Outcome

Real product questions, no launch

There was no ship. The process ended when the startup passed on me over a compensation gap — not a fit or quality gap, and they were direct and warm about wanting to stay in touch.

Trip product architecture: object model and lifecycle framework

🏗️ Object model defined

Composite state architecture for trips at any completeness stage — from dream to remembered.

🔍 Isolated differentiator

Competitive teardown surfaced the persistent-trip gap no booking platform addresses.

🤝 Founder-level depth

Multiple sessions working through open product questions the way an in-team designer would.

The more useful signal isn't a launch metric — it's that cofounders worked through real, still-open product questions with me across multiple sessions, the way they'd work through it with someone already on the team, not the way you give portfolio-review feedback to a candidate.

06 • Reflection

What I'd pressure-test next

Two things stayed genuinely unresolved, and I think leaving them that way was the right call rather than a gap to paper over.

What stayed open. Whether AI alerts during the Live phase should go to every traveler or just the Coordinator, and a bigger strategic question I surfaced but didn't force an answer to — whether the product should own bookings outright, aggregate third-party inventory, or stay purely a coordination layer around bookings happening elsewhere. That last one changes almost everything downstream of it, and I'd rather name it honestly than pretend a few conversations were enough to settle a decision that big.

What I'd revisit first. The permissions model — three modes chosen at trip creation is clean in theory, but I'd want to watch a real Managed-mode trip (an assistant building for an executive) to see whether "low-stakes vs. structural" actually holds up as a distinction once real edits start happening, or whether it needs to be more granular than I designed it.