Case study, Roam, Side Project, 2025
Roam: from idea to working web app in 80 hours
A solo sprint to design and ship an AI-first travel planning app — from blank canvas to published product — using Figma Make and the Anthropic API.
Total time
Core screens
Engineers involved
Role
Solo designer and builder
Timeline
80 hours total
Stack
Figma Make, Anthropic API, Framer
Status
Live prototype, in progress
Context
Try it out
An 80-hour solo sprint to design and ship an AI-first travel planning app from scratch. Ideated with Claude, built a token system and wireframes in Figma Make, designed hi-fidelity screens with a full component library and design system, then used the Figma MCP with Cursor to translate designs into code, committed to Github, deployed on Vercel, and QA'd against design specs until it shipped without bugs. This case study covers the problem it was built to solve, the three core product surfaces, and what's still left to build.
Stack
Technical stack
Context
A personal frustration that became a product question
Planning a group trip is still a surprisingly broken experience. You start in a WhatsApp thread, end up in a Google Doc, consult a few travel blogs, and somehow consolidate everything in a spreadsheet. There’s no shortage of travel apps, but most of them search for things you already know you want. They don’t help you figure out what you want in the first place. After planning a trip to Ksamil, Albania with two couples — coordinating ferry timetables, accommodation, beach recommendations, restaurant reservations, and daily budgets across multiple tools — the question felt real: could a single AI-native interface replace all of that without it feeling like yet another chatbot? Roam was the attempt to find out. The constraint was deliberate: not a portfolio exercise, but a real thing, built from scratch, with a hard time budget of 80 hours.
Stack
Technical stack
Problem
Travel planning is fragmented by design
Existing tools are built around search, not discovery. They optimise for people who already know where they’re going, for how long, and at what budget. They don’t handle the earlier, messier phase — the “we want to go somewhere warm in late June, we have four people, not sure how long” conversation that most real trips actually start with.
Core problem statement
How do we reduce the cognitive work of building a complete outfit from hours to minutes, while earning enough trust that shoppers actually act on the recommendations?
"I can find individual pieces I like but I never know if they're going to work together until I'm standing in front of a mirror. By then I've already paid for everything."
Usability test participant, 2023
Approach
Constraint as a creative forcing function
The 80-hour budget was not just a timeline — it was a design constraint. Every decision had to be defensible against a single question: does this justify the time? That discipline shaped the scope more cleanly than any brief could have. Rather than designing exhaustively in Figma and handing off to a developer, the entire project was built inside Figma Make — Figma’s AI-assisted build tool — which meant design and build decisions happened simultaneously. The Anthropic API powered the core planning feature — natural language trip input, preference gathering, and day-by-day itinerary generation.
Core build stack
The project combined AI-assisted interface generation, live itinerary logic, and a Framer publish pipeline into one fast design-build loop.
PRODUCT SCREENSHOT
Figma Make
Design and build environment
Used to move from natural-language prompts to live, interactive UI instead of static handoff frames.
PRODUCT SCREENSHOT
Anthropic API (Claude)
Planning intelligence
Powered preference gathering, budget-aware suggestions, and day-by-day itinerary generation.
PRODUCT SCREENSHOT
Framer
Publish and prototype layer
Used to publish the working prototype and shape the responsive case-study-ready experience.
Design and build decisions happened simultaneously
Because the AI generated functional code from natural language prompts, the work shifted from pixel-perfecting static frames to responding to live output. Design decisions were made in the product, not around it.
JOURNEY DIAGRAM
Figma Make prompt → live UI → Anthropic API → itinerary output loop.
The planning model had to feel specific
Claude handled everything from clarifying traveller count and budget tier to surfacing real location suggestions with reasoning attached. The system needed to ask before it answered, then return structured outputs the interface could render predictably.
USER FLOW DIAGRAM
Preference gathering and itinerary generation were split into two separate API calls to prevent generic output.
What the product had to solve
01
No AI-native planning layer
Booking platforms bolt AI on top of existing search UIs. Roam’s question was whether you could design the planning layer as an AI-first conversation from the start — not a feature added later.
02
Group trips are an unserved use case
Most apps assume one traveller making one decision. Multi-person trips with shared preferences, split costs, and competing interests are almost entirely unaddressed.
03
The gap between inspiration and booking
There’s a dead zone between “I want to go somewhere” and “here are the hotel results.” No tool lives in that gap with any intelligence. Roam was designed to live there.
04
Itineraries have no visual home
Once you’ve decided where to go, the itinerary lives in a notes app or a spreadsheet. A day-by-day, map-integrated view with cost estimates doesn’t exist as a lightweight standalone tool.
Process
Eighty hours, sequenced
The sprint was divided into five phases, each with a hard time ceiling. When a phase ran long, scope was cut — not quality.
Hours 0–12 · Define and map
TRIP BRIEF SCREEN
User flow mapping, competitor audit across Wanderlog, TripIt, Google Travel, and Airbnb Experiences. Three primary surfaces identified: onboarding brief, AI planning chat, day-by-day itinerary view.
Hours 12–28 · Design system and onboarding
AI CHAT SCREEN
Visual language set in Figma Make: warm neutral palette, Outfit typeface, teal accent, card-based layout. Onboarding flow built — destination, traveller count, dates, budget tier.
Hours 28–48 · AI planning interface
ITINERARY SCREEN
ITINERARY DETAIL
ACCOMMODATION SCREEN
MOBILE PLANNING SCREEN
Core chat interface built and wired to the Anthropic API. Prompt engineering for clarifying questions, preference gathering, group size, and budget constraint handling. Itinerary output format designed.
Hours 48–68 · Itinerary view and map
Day-by-day itinerary screen with time blocks, cost estimates, and location pins. Map embed integrated. Accommodation picker screen built. Mobile-responsive layout pass.
80-HOUR TIMELINE
Hours 68–80 · Polish and publish
DAY 1 BUILD SCREENSHOT
DAY 2 BUILD SCREENSHOT
DAY 3 BUILD SCREENSHOT
Micro-interactions, loading states, empty states, error handling. Published via Framer. Final QA on mobile and desktop.
The time ceiling made scope decisions fast and unambiguous. Cost splitting, social sharing, saved accounts, and real booking integrations were cut so the core planning loop could become real.
Design
Three surfaces, one coherent journey
Roam’s interface was built around a three-act structure: tell us about your trip, let us plan it with you, then explore and refine the result. Each surface had to feel like a natural step in the same tool — not three separate product decisions stitched together.
Rather than a blank search bar, Roam opens with a structured brief — destination, dates, travellers, budget tier. A deliberate departure from conversational-first design: most people don’t want to type an essay to start a trip. They want to answer a few clear inputs and then let the AI work.
TRIP BRIEF SCREEN
Once the brief is submitted, Roam enters a short clarifying conversation before generating anything. The AI asks two or three targeted questions first — activity preferences, must-sees, dietary requirements, pace — so the output feels earned rather than generic.
AI PREFERENCE CHAT SCREEN
The itinerary screen is structured as a vertical timeline with one card per activity — arrival, accommodation, meals, sights, transport. Each card shows a time, location, estimated cost, and a short AI-written note explaining why it was included.
DAY-BY-DAY ITINERARY SCREEN
Roam suggests accommodation options filtered by the selected budget tier. Each card includes name, location, nightly rate estimate, and a brief rationale so the recommendation feels advisory instead of arbitrary.
ACCOMMODATION PICKER SCREEN
The day’s activities are plotted on an embedded map with location pins. Real-time routing and deep-linked navigation were intentionally left out of scope for the 80-hour sprint.
MAP-INTEGRATED PLANNING SCREEN
The itinerary layout adapts for mobile with day tabs and stacked activity cards, keeping the planning loop usable on the device people actually carry while travelling.
RESPONSIVE MOBILE PLANNING SCREEN
Integrating the Anthropic API meant that one of the most important design artefacts was the system prompt — not a Figma frame. Getting the AI to produce itineraries that felt specific, useful, and appropriately scoped took as much iteration as any screen design.
AI planning logic
AI design
Designing the prompt as much as the interface
Prompt engineering is interaction design. The most impactful decisions weren’t about layout or colour — they were about how the AI was instructed to behave. Writing the system prompt with the same rigour as UX copy changed the output quality dramatically.
CLOSING PRODUCT IMAGE
The AI was prompted to return itinerary data as a consistent JSON structure — time, location, category, cost estimate, reasoning note — so the UI could render it predictably regardless of destination or trip type. Preference gathering and itinerary generation were split into two separate API calls, and the selected budget tier was injected into the system prompt as a hard constraint.
Reflection
What 80 hours teaches you about building
The most impactful decisions weren’t about layout or colour — they were about how the AI was instructed to behave. Writing the system prompt with the same rigour as UX copy changed the output quality dramatically.
When you’re designing in a tool that generates live code from prompts, the feedback loop is different. You don’t design a screen and then build it — you refine a screen that already works.
Cutting the cost-splitting feature and the social sharing flow wasn’t just project management — it was choosing which problems the product was actually trying to solve.
Every AI travel product I looked at during the competitor audit generates output immediately. The two-step pattern — gather context, then generate — produced significantly more specific itineraries.
A production version would need a proper backend, user accounts, saved itineraries, real booking integrations, cost splitting for group trips, and proper map routing.
Outcome
Something real, built by one person
This project was never primarily about finishing Roam. It was about testing how fast a concept could move from ideation to something real and published — using the AI tools now available to a designer working solo. The answer, it turns out, is 80 hours. Not a polished product. Not a throwaway prototype. Something in between: a working, AI-powered web app that solves a real problem, built by one person without engineering support.
Trip brief / onboarding
Destination input, traveller count, date range picker, and budget tier selector. Fully interactive.
AI preference chat
Two-turn conversation powered by the Anthropic API before itinerary generation.
Itinerary generation and display
Day-by-day view with activity cards, cost estimates, AI-written reasoning notes, and switchable day tabs.
Map integration
Day activities plotted on an embedded map; live routing remained out of scope.
Mobile responsive pass
Responsive layout for itinerary tabs, activity cards, and destination planning on mobile.