Founding, designing and building a travel-planning beta that brings a multi-stop route, itinerary and connections into one editable plan.
- Role
- Founder, product design and AI-assisted building
- Team
- Independent product
- Company
- Morrovia
Beta
Product stage
No established adoption, revenue or conversion outcomes.
AI-assisted
Design-to-build workflow
Multi-modal
Connected journey planning
Editable
Traveller stays in control
The Problem
A multi-stop trip is a system of connected decisions: where to go, how long to stay, how to get there and what changes when one stop moves. Those decisions are often scattered across maps, spreadsheets, booking sites and notes. A convincing itinerary is only useful if the journey works in practice.
What I Did
I shaped the product direction, planning flows and interface, using AI-assisted implementation to turn design decisions into working screens. The focus is one editable plan, visible uncertainty and traveller control.
The Outcome
Morrovia is a public beta bringing route planning, itineraries and connections into one editable workspace.
Product vision
A living plan, from first idea to departure
The vision is a planning companion that helps someone shape a complex trip without losing control of it. A route is the starting point, then places, nights, activities and transport become parts of the same plan. The experience should support both exploration and practical decisions: what could this trip look like, and what still needs checking before I rely on it?
Decision 01 / 03
Start with intent, not a long form.
The public homepage offers two starting points: choose stops or describe a trip. I designed the flow around turning that intent into a suggested route the traveller can review and change.
The aim is a useful starting point with visible assumptions, rather than a finished answer to accept. The itinerary brings day-by-day planning and activity ideas into the same workspace.
Design principle → a starting point the traveller can change
Decision 02 / 03
Make the journey between places realistic.
A route on a map is not proof that a connection works. I designed distinct states for transport mode, planning estimates, booking status and transfers that need checking.
The public experience presents travel between stops and flags timing to confirm.
Design principle → show uncertainty where the decision happens
Decision 03 / 03
Treat the saved trip as the product.
My Trips gives the plan a place to return to. I designed the route, itinerary and map as connected views of the same saved trip, so travellers can pick up their planning where they left off.
Design principle → reliability earns the right to feel simple
AI-assisted building
Close the gap between a design and a working product
As founder and designer, I moved between product direction, interaction design and AI-assisted implementation. I defined the trip structure, editing flows, uncertainty states and recovery behaviour, then used working screens to expose constraints a static prototype could hide. AI supported implementation and iteration; product judgement, review and verification remained my responsibility.
Beta outcomes
What the beta shows so far.
Stage
Beta; still being validated
Product evidence
Search, itinerary, transport and saved-trip map
Commercial outcomes
No verified figures reported
Release scope
Public beta
Lessons and next steps
Trust is part of the interface
An estimate, a booking and a connection needing confirmation must feel different. Clarity about uncertainty is as useful as the recommendation itself.
Reliability comes before polish
A beautiful generated itinerary is not enough. Editing, saving, reopening and recovery determine whether someone can depend on the plan.
Validate with real planning
Use observed travel-planning sessions to assess comprehension and friction. Establish a baseline before reporting adoption or business impact.
Next case study