Browsing Florence, no accountGiving a travel group one place to turn competing preferences into a decision.
A travel-discovery concept evolved from research into a live prototype with bookings, reviews, and crew voting.
- RoleResearch synthesis, flows, AI-directed build
- TimelineLive build, August 2026
- StatusLive prototype with seeded experiences
I recorded research sessions, synthesized findings, and designed flows and prototypes. I later directed AI agents through the live build.
The problem
On a two-day trip, a review count and a listicle don’t tell you if an activity is worth half a day. I recorded interviews to understand how travelers actually decide.
I mapped the responses into an affinity chart, drew two personas grounded in what people said, and built a six-screen prototype. The prototype made those flows concrete. It was not an external usability test.


What the research found
The journey map showed that checking everyone’s availability was the actual hard moment. That changed what I built next.
The trip owner now proposes two to four times. Friends open a share link and vote In, Maybe, or Out without an account. The crew coordination gap the interviews exposed became the core product design.
- 01ProposeOwner offers 2 to 4 times
- 02ShareFriends open a plan link
- 03VoteIn, Maybe, or Out without signup
- 04CompareOwner reviews availability
Live prototype, August 2026
I directed an AI-directed build on Supabase with a warm-paper interface and a seeded experience catalog. The prototype includes email login, a booking flow with confirmation codes, crew voting using share tokens, messaging to hosts, and a gallery of experiences.
Crew coordination without signup
Share tokens let friends vote In, Maybe, or Out. Invalid tokens return no data. The trip owner sees votes in real time.
Trust through booking status
Reviews can be posted by anyone but only show verified when the writer has a confirmed booking.
Host messaging
Guests message hosts directly. The system supports live delivery and contextual responses.
Data isolation
The app shares infrastructure with this portfolio but uses namespaced tables and row-level security to keep data separate.
The core design choice was putting crew coordination first. That interface is the differentiator, not the activity catalog.

Shipped state
The live prototype has seeded experiences. The build includes functional reservation and share-link voting flows, not evidence of customer adoption. No external usability validation has been done yet.
Next, I would test coordination with real travel groups before expanding the catalog. The question is whether proposing a few times and removing signup actually helps people agree.
Interviews and affinity maps from research phase. Live build is August 2026. Personas and coordination flow are grounded in what travelers said.
