Planning a trip is not one decision.
It’s a chain of uncertain, interdependent choices:
Where to go,
how to plan,
who to travel with.
Today, most self-planned trips are planned across:
scattered tools
informal conversations
disconnected decisions
This applies whether you:
plan solo
already have people
or look for someone to travel with
The problem is the same:
understanding if decisions align.
Words like “cheap” or “intense” don’t mean the same thing to everyone.
This is where misalignment begins, escalating during planning or during the trip.
That’s why:
people drop out
avoid traveling together
or end up in experiences that don’t work.
The problem is not lack of options.
It’s aligning decisions:
between people,
their expectations,
and the way they travel.
Most tools support communication and booking.
None support alignment.
Instead of helping users explore more, I focused on helping them decide better.
This created a foundation for all further product decisions — from how users enter the product, through how AI supports them in each moment, to event-based monetization.
I framed the product as a system of decisions throughout the entire travel journey.
Planning a trip doesn’t happen in one moment.
It unfolds across multiple stages — from finding people and ideas, through planning and preparing, to real-time decisions during the trip.
Most tools focus on isolated parts of that journey:
discovery
planning
booking
But none support how decisions evolve across all of them.
Instead of focusing on a single feature, I designed the product as a system that supports decisions across the entire journey:
Before → Discovering people and plans
During planning → Structuring decisions and alignment
Before trip → Preparation
During trip → Real-time decisions
After trip → Learning and reflection
Users enter the product from different starting points.
Designing a single flow would flatten these differences.
I defined three main entry scenarios:
I want to travel, but don’t have people
I have people, but we need alignment
I travel solo, but need structure
Each scenario represents a different job to be done:
find the right people
align decisions
structure the perfect trip
Main use cases
The feed brings together travel plans and people in one place.
Users don’t have to decide where to start. They immediately see what’s relevant to them — plans to join, people to travel with, or ideas to build on.
Instead of navigating features, they start from real possibilities.
User modeling pipeline
Instead of a static profile, I introduced a dynamic user model.
People don’t travel the way they describe themselves.
Declarations are static.
Behavior is contextual and evolving.
Instead of relying on a fixed profile,
I designed a dynamic user model that evolves over time.
It combines:
initial onboarding (starting point)
refinement (increasing confidence)
real behavior (source of truth)
Behavior overrides declarations. Confidence increases with repeated actions.
The model doesn’t ask who the user is.
It observes how they travel.
Built across key dimensions:
pace · decision style · spending · social · conflict · priorities
This enables the system to:
→ prevent mismatches before decisions are made
→ reduce friction in group planning
→ adapt recommendations in real time
→ increase plan completion
Archetypes
The model is not exposed directly. Its complexity would make it unusable in social contexts.
To make it actionable for users, I introduced a simplified layer of archetypes.
Archetypes translate behavioral signals into a form that is easy to read and compare.
Instead of asking: “Who is this person?”
Users quickly understand:
how someone travels
how they make decisions
where they might align
Archetypes are derived from the model, but they don’t define it.
They are:
compressed
dynamic
intentionally imperfect.
Their role is legibility.
For deeper understanding of potential match, the system provides explainability at the moment of decision — showing where users and plan align and where they differ.
The same user model becomes the foundation of the matching system.
Archetypes
I built a matching system based on multiple signals rather than a single outcome.
Most systems reduce matching to a single score.
But in travel, alignment is not binary:
context matters
behavior outweighs declarations
differences are inevitable
Instead of a single score,
I built a multi-signal decision model.
The system evaluates:
current intent
plan context (pace, budget, owner’s travel identity, etc.)
user model (preferences and behavior)
tolerance for differences
Signals are weighted dynamically,
depending on context.
Instead of producing a single score, it surfaces where alignment matters most in the current context.
This define system propositions — plans, users, and plan structures — across different use cases.
The system distinguishes:
fit → where things align
tension → where differences may create friction
Matching engine
Each user has not only preferences, but also a range of tolerance.
This allows the system to work as a gradient, not a binary match — assessing whether differences are acceptable in a given context.
Users don’t just see a match.
They see:
where it works
where it might create friction
so they can make conscious decisions, before it becomes a bad trip.
This applies whether they choose a plan, a person, or an activity.
Tolerance matrix
The model works in the background. Its value appears only when users understand its decisions.
Most systems hide the logic. This one makes it visible.
It explains how decisions are made — reducing uncertainty and preventing bad choices.
These foundations turned system logic into clear user choices.
The same logic applies across the entire journey:
matching
planning
preparation
real-time decisions
The system makes decisions understandable, so users stay in control. It continuously interprets user signals, updates the model, and recalibrates recommendations over time.
Users see:
→ where they align
→ where they differ
→ and what those differences mean in practice
Matching stops being a result.
It becomes a decision point.
A plan is more than an itinerary.
It carries context — pace, budget, and group dynamics.
Profiles make compatibility tangible.
Beyond the match, they reveal:
past trips
reviews
roles and preferences
travel history
Users know what to clarify.
Example user flow for creating plan with others
Plans can be shaped together —
before committing.
Users see where they align, what needs discussion, and how to proceed.
Every plan starts with a context.
Users define:
who the trip is for
how open it is
key constraints
This sets the boundaries for who they will be traveling with.
The system suggests places directly on the map, based on:
distance
timing
preferences
plan structure
In advanced scenarios, it even suggests the optimal flow.
No guesswork.
Every plan has preparation support.
It starts from the trip context — what the trip is, when it happens, and how it’s planned.
The system translates the plan into concrete needs.
Not generic lists.
No missing essentials.
Items grounded in destination, timing and activities.
Users decide:
what they already have
what they don’t need
what’s missing
The system turns that into a cart, based on availability and budget.
No starting from scratch.
Just review, adjust, or accept.
Users get what matters for their trip based on their plan:
entry requirements
health and safety
weather and local conditions
culture and cuisine insights
Users see what’s happening around them — people, places, and context-aware recommendations.
They can explore intent and get suggestions aligned with the plan.
In the moment.
Users reflect on:
→ how the trip felt
→ how well they matched with others
→ how much they spent
→ and what they would change
The system learns what actually worked — and improves future decisions.
Trips become part of a personal travel history.
Users see what they’ve explored — and build a visible record of their journeys.
This closes the loop — from decisions to better decisions over time.
What seemed like separate decisions across the product became one system that organizes how users
plan,
decide
and act.
Product Strategy
All product decisions are connected through a single system.
User behavior is continuously interpreted, feeding into a decision model that adapts over time.
AI is not a feature.
It’s a layer that:
interprets signals
adapts recommendations
explains decisions
All filtered through context and intent.
It determines what to show, what to prioritize, and when to prompt the user for a decision.
The output is not a fixed result, but a set of guided decisions across the journey.
“Is this right for me?”
“How should I plan this?”
“What do I need to prepare?”
“What should I do now?”
Each decision improves the model, making the system more accurate, adaptive, and harder to replicate.
More users → more interactions
More interactions → better matching
Better matching → more users
AI decision model
User Experience
The system turns fragmented decisions into a clear and adaptive travel experience.
Where to go.
With whom.
How to make it work.
The user can start in different ways:
exploring ideas
looking for people
or building a plan
As they move forward, the system:
helps define what the trip is about
structures decisions into clear steps
shows where users align and where they differ
Planning no longer happens across chats, notes, and tabs.
Everything lives in one place — shared, visible, and adjustable.
While building the trip, the system supports decisions with recommendations:
places and activities that fit the destination
suggestions aligned with the user’s travel style
options shaped by the intent of the trip
Before the trip, the system prepares the user:
what to bring
what might be missing
what to expect
Based on destination and the intent behind the trip.
During the trip, the system supports real-time decisions:
suggests what to do next based on context
updates the plan as it changes
surfaces places, activities, and people that fit
Suggestions evolve with the user — based on behavior, context, and previous decisions.
If plans change or nothing is planned, users can:
discover nearby options
meet compatible travelers
The result is not just a better plan, but a more confident and flexible way of traveling.
Business Strategy
Designed for scale, growth and monetization.
Event-based monetization embedded in the journey.
Instead of subscriptions, monetization is tied to moments of use:
planning a trip
traveling
Model
FREE → discovery
PLAN PASS → building a trip
TRAVEL PASS → real-time support
Users unlock value only when they need it.
What users pay for
Plan Pass (before trip):
advanced filters for recommendations
AI-assisted planning
smarter plan structure
Travel Pass (during trip):
extended nearby people & places
“what to do now” AI support
Plan & Trip Pass:
covers the entire journey
pricing based on trip duration
Additional revenue
Affiliations
attractions
accommodation
tickets
Marketplace
insurance
travel-related products
How conversion happens
Access is not blocked.
Value increases with specific intent.
Triggers:
building a plan
preparing for a trip
real-time exploration
Users see better outcomes,
then choose to unlock them.
Early Product-Market Fit
Validating the core value first
Can better alignment lead to better trips?
Hypothesis
If users:
better understand who they travel with
see differences early between their style of travelling and plans
co-create a plan
and get more tailored recommendations for plan structure
then:
they will feel more confident
create better plans
and be more willing to travel
MVP Scope
Instead of building the full product, I would focus on the core loop:
matching (user ↔ plan / user ↔ user)
shared plan creation
visible alignment and differences
AI recommendations for plan structure based on context (next stage)
Excluded:
preparation features
shop
travel map
advanced real-time support
To validate this, I would observe:
do users create plans after matching
do they use AI recommendations
do they continue the interaction
Signals of value would be:
users move from matching → plan creation
plans are iterated, not abandoned
users express confidence in the match
User Lifecycle
Measuring performance across the full lifecycle
The goal is not engagement, but completed trips.
The product is structured around the full journey:
discovery → planning → preparation → travel → reflection
North Star Metric
Trips successfully planned and executed
This reflects the core value of the product: helping users move from idea to real experience.
It applies across all use cases:
solo travel
group travel
AI-assisted planning
A successful trip includes:
a plan created
decisions supported by the system
execution during the trip
Stage metrics (proxies)
Different use cases follow different paths, but converge on the same outcome.
Stage metrics help identify where users struggle to reach value, and how the system can support them better.
Discovery
profile completion
% users who start or remix a trip
% users who engage with matching (user–plan / user–user)
social → matches initiated
Planning
places added
AI interactions
social → matches accepted
fit confidence score of matches
Plan Pass conversion rate
Preparation
packing completion rate
packing → shopping conversion rate
engagement with contextual information (“what to know”)
Plan Pass conversion rate
Travel
daily active usage during trip
interactions with map
interactions with AI
real-time decisions
Travel Pass conversion rate
Reflection
feedback submitted
retention (next trip within X time)
Core hypothesis
Better decisions → better trips → repeat usage
This project showed that what seem like different decisions — product, experience and business — are in fact different perspectives of the same system.
Designing it meant aligning these perspectives
into one coherent logic.
Only then the product becomes clear,
scalable — and the experience meaningful.
