Case Study 02
Romi
Romi is an AI powered group travel coordination platform, and the clearest example of being a product designer who builds. As co-founder, I designed the two sided product end to end, trip managers planning the trip and travelers joining it, then used Figma's MCP server to bring the design system into code and built the React front end myself.
Interactive prototype with sample data. Not the production app. Start as Alex to create a trip, then join as Marcus with code BCN2026.
Problem
The why
We interviewed 40 people before writing a single line of code. The pattern held across almost all of them: group trips don't fall apart because people don't want to travel together, they fall apart because planning them is fragmented and stressful enough that trips quietly never happen. Romi exists to replace that fragmented thread with one shared surface.
Sizing the opportunity
Gen Z backs this up: the average Gen Z traveler spends $11,766 a year on travel, 74% of millennials and Gen Z call it a non-negotiable expense, and 44% of Gen Z take four or more trips a year. The travelers who need Romi most are also the ones already spending the most to get it wrong.
Who I designed for
The Trip Manager
Plans, invites, decides
Sets up the trip, narrows the date windows down to ones that actually work, and makes the final call on flights and modules for the whole group.
The Traveler
Joins in one tap
No account needed to join. Submits availability and a private budget range, then lets Romi and the manager handle the rest.
Hypothesis
If the manager and each traveler had their own simple surface, shared where a decision was needed, private where it wasn't, the group thread could disappear entirely.
Mapping the flows
Every flow in Romi follows the same three-phase structure: ideation, where each person privately submits availability and budget, planning, where Romi surfaces the best dates and flights for the group, and execution, where everyone books and locks in details together.
Manager onboarding
Traveler onboarding
Coordination
Command center
Setting up the trip
Landing screen: the pitch, and the two entry points, create or join
Step 1 of 4: trip basics, with a live preview of what travelers will see
Step 2 of 4: date windows instead of a single pick, so Romi can find real overlap
Choosing what to coordinate
Only 3 of 6 modules are required to start. Dates, flights and budget ship first, the rest opt in anytime, so a manager never has to decide everything up front.
Modules step: pick what the group needs help with, turn on the rest later
Joining as a traveler
Joining takes one tap, no account required
Availability is yes, maybe or can't, not a binary, so partial overlap still counts
Budget stays private. Romi uses the range only to filter, nobody in the group sees the number
Coordinating as the manager
Every traveler's response rolls up into a per window match score
Romi finds flight packages that land the group within a shared arrival window, and flags anyone over budget before it's booked
The command center
One dashboard tracks planning progress, flags what still needs a decision, and shows every traveler's status at a glance
How I built it
I designed every screen in Figma, then used Figma's MCP server to bring the design system straight into code. I built Romi's React front end myself, screen by screen, to take it from a clickable prototype to a working product.
Business model
Free tier
Trip creation, date and budget inputs, basic group alignment and the dashboard view are free for every trip.
Credit system
AI itinerary generation, optimized flight bundles and advanced filtering are paid add-ons, so travelers only buy what they actually need.
Longer term, affiliate partnerships, starting with flight search through Skyscanner and Amadeus, then boutique hotels, then direct airline deals, turn booking volume into recurring revenue without charging travelers more.
Results
What's next
AI integration
Smarter coordination and planning, so Romi recommends instead of just surfacing optionsDirect booking
Booking flights and locking in details without leaving RomiExpansion
Growing through young professional networks, starting in AustinWhat I learned
Key learnings
- Two-sided products double the edge cases. Every decision for the manager had a mirrored consequence for the traveler, so flows needed testing in both directions, not just from the manager's seat.
- Designing with code in mind changes the file. Structuring components to translate cleanly through Figma's MCP server into React meant thinking about states and variants earlier than I would on a design-only project.
What I would do differently
- Build and design in parallel sooner. I locked more of the Figma file before starting the React build than I would next time; moving flows into code earlier would surface technical constraints sooner.
- Bring in traveler feedback earlier. Most early testing happened from the manager's side, since that's the harder flow to get right. Travelers deserve earlier input too.