Case study, Roam, Side Project, 2025
Roam: from idea to working web app in 50 hours
A solo sprint to design and ship an AI-first travel planning app, using a chain of 13 AI tools from the first conversation in Claude Desktop to production deploy on Vercel.
Total time
AI tools used
Engineers involved
Role
Solo designer and builder
Timeline
80 hours total
Stack
Figma Make · Figma Agent · Claude Code · Cursor · React · Vercel
Status
Live at roam.akberahmed.com
Live product
Try it live
Roam started as a question: could one designer build and ship a fully functional AI product without an engineering team? The answer is what you're looking at.
Roam started as a question: could one designer build and ship a fully functional AI product without an engineering team? The answer is what you're looking at.
Enter a destination, set your dates, traveller count and budget, and the app generates a real day-by-day itinerary. Live location data comes from Google Places. Hotel pricing pulls from Xotelo. The planning intelligence runs on the Anthropic API. Everything from the first wireframe to the deployed app was designed in Figma and implemented in React by one person.
This wasn't a prototype made to look real. It is real. Try planning an actual trip.
60 hours. 13 AI tools. 0 engineers.
Click through the prototype to try it
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.
01
No AI-native planning layer
Booking platforms bolt AI on top of existing search UIs. The question was whether you could design the planning layer as an AI-first conversation from the start, not as 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 view with cost estimates doesn't exist as a lightweight standalone tool.
Process
Seven phases in 50 hours
The sprint moved through seven distinct phases, each using a different tool. When a phase ran long, scope was cut, not quality.
Phase 01 · Hours 0–6
Ideation with Claude
Before opening a design tool, the product concept was stress-tested in a Claude Desktop session. The conversation started with the problem: what makes group travel planning broken? Claude pushed back, asked clarifying questions, and helped map the core user journey.
The output wasn't a document. It was a set of decisions: three primary surfaces, two API integrations, one hard time constraint. That session gave the project a shape before the design work began.
Phase 02 · Hours 6–14
Wireframes in Figma Make
Figma Make generated the initial screen set from natural language prompts. The brief was direct: a travel planning app with an input form, an AI planning flow, and an itinerary view. What came back was nine screens.
Several were kept almost unchanged in the final build. The speed wasn't just convenient; it was a forcing function. With working screens available in hours rather than days, the decision-making moved to interaction and flow rather than layout.
Wireframes generated with Figma Make.
Wireframes generated with Figma Make.
Phase 03 · Hours 14–26
Hi-fi design + Figma Agent
With the wireframe structure confirmed, Figma Agent populated the high-fidelity frames with real content. Albania itinerary views, accommodation cards, and restaurant listings appeared without typing a single entry.
This was the point where the visual direction became concrete. The design went from placeholder boxes to something that looked and felt like a real product. Figma Agent handled the content; the design work shifted to refining layout, spacing, and how each screen connected to the next.
Token reference sheet. Feel free to scroll within it.
Figma Agents helping make variants of the screens.
Phase 04 · Hours 26–34
Design tokens to CSS
Token Studio exported the Figma design system as CSS custom properties. The terminal output shows the complete variable set: colours, spacing scales, border radii, and typography. Rather than hardcoding values, the app's visual system was driven entirely by tokens that matched the Figma variables exactly.
This made the design-to-code handoff precise. When a colour changed in the Figma file, it changed in the token export. When the token export changed, it changed in the app. The three-way connection between design intent, tokens, and code stayed in sync throughout the build.
Phase 05 · Hours 34–38
API setup and system prompt
Three production API keys were generated: Anthropic for the AI planning layer, Google Places for location data, and Xotelo via RapidAPI for live hotel pricing. Each one connected a design decision to a working data source.
The Anthropic setup also involved writing the system prompt. The two-phase generation pattern, preference gathering before itinerary output, was defined here. The prompt instructed Claude to ask two or three targeted questions before producing anything, and to include a one-sentence rationale for every suggestion. That framing shaped the entire interaction model.
Phase 05 · Hours 34–38
API setup and system prompt
Three production API keys were generated: Anthropic for the AI planning layer, Google Places for location data, and Xotelo via RapidAPI for live hotel pricing. Each one connected a design decision to a working data source.
The Anthropic setup also involved writing the system prompt. The two-phase generation pattern, preference gathering before itinerary output, was defined here. The prompt instructed Claude to ask two or three targeted questions before producing anything, and to include a one-sentence rationale for every suggestion. That framing shaped the entire interaction model.
Phase 06 · Hours 38–46
Figma MCP + Claude Code
Claude Code connected to the Figma file via the MCP server integration. Rather than describing components from a screenshot, Claude fetched the actual node metadata: component properties, spacing values, layout constraints, and typography settings. Each React component was implemented directly from the live spec.
The visual output matched the Figma design without manual translation. Spacing came from the component, not from estimation. Colours came from the tokens, not from eyeballing. This was the phase that made the "design-to-code gap" feel like a solved problem rather than a friction point.
Phase 07 · Hours 46–50
Build sprint and production deploy
The final sprint used Cursor and Vite's hot module replacement to keep the iteration loop tight. A change in code appeared in the browser within two seconds. Edge cases, loading states, and error handling were worked through in real time rather than in a separate QA pass. The Vercel deployment took under two minutes. The app went live with three working API integrations, mobile-responsive layouts, and a production URL. Fifty hours in, Roam was a real thing that worked.
Context
Three surfaces, one coherent journey
Roam's interface was built around a three-act structure: tell us about your trip, let the AI plan it, 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.
1. The trip brief
Rather than a blank search bar, Roam opens with a structured brief: destination, dates, travellers, budget tier, transport preferences, and activity interests. A deliberate departure from conversational-first design: most people don't want to type an essay to start a trip.
The brief also doubles as the AI's context window. By the time the user submits, the model has everything it needs to generate a specific itinerary without a round of vague follow-up questions. The form is doing work that would otherwise fall to the AI.
2. Itinerary reveal
Once the brief is submitted, Roam processes the inputs and generates a full day-by-day itinerary. The reveal screen confirms that planning is complete and transitions into the result view, where the traveller can explore the output.
The decision not to show a chat interface was intentional. Most AI travel tools make the user converse their way to a result. Roam front-loads the context collection in the brief, so the AI can go straight to generating without the back-and-forth. The itinerary feels earned rather than extracted.
Accommodation options
The accommodation picker surfaces three AI-suggested options filtered by the budget tier selected in the brief. Each card includes the hotel name, location, nightly rate pulled from the Xotelo API, and a short rationale for why it was included. The reasoning note matters: accommodation suggestions that just list prices feel algorithmic. Roam's version explains its thinking.
AI design
Designing the prompt as much as the interface
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.
01
Structured output format
The AI was prompted to return itinerary data as a consistent structure: time, location, category, cost estimate, reasoning note. This let the UI render it predictably regardless of destination or trip type.
02
Brief as context injection
The trip brief form feeds directly into the system prompt. Every field the user completes, budget tier, transport preferences, interests, becomes a constraint the model reasons within rather than a question it has to ask.
03
Budget tier as a hard constraint
Essential, Comfort, and Premium weren't just UI labels. They were injected into the system prompt as hard constraints, calibrating accommodation, dining, and activity suggestions to the same tier throughout.
04
Reasoning-first outputs
The prompt instructed the AI to include a one-sentence rationale for every suggestion. This made outputs feel advisory rather than algorithmic, and matched the core insight from the Muse project: unexplained recommendations don't build trust.
Phase 03 · Hours 14–26
Hi-fi design + Figma Agent
With the wireframe structure confirmed, Figma Agent populated the high-fidelity frames with real content. Albania itinerary views, accommodation cards, and restaurant listings appeared without typing a single entry.
This was the point where the visual direction became concrete. The design went from placeholder boxes to something that looked and felt like a real product. Figma Agent handled the content; the design work shifted to refining layout, spacing, and how each screen connected to the next.
Phase 04 · Hours 26–34
Design tokens to CSS
Token Studio exported the Figma design system as CSS custom properties. The terminal output shows the complete variable set: colours, spacing scales, border radii, and typography. Rather than hardcoding values, the app's visual system was driven entirely by tokens that matched the Figma variables exactly.
This made the design-to-code handoff precise. When a colour changed in the Figma file, it changed in the token export. When the token export changed, it changed in the app. The three-way connection between design intent, tokens, and code stayed in sync throughout the build.
Phase 05 · Hours 34–38
API setup and system prompt
Three production API keys were generated: Anthropic for the AI planning layer, Google Places for location data, and Xotelo via RapidAPI for live hotel pricing. Each one connected a design decision to a working data source.
The Anthropic setup also involved writing the system prompt. The two-phase generation pattern, preference gathering before itinerary output, was defined here. The prompt instructed Claude to ask two or three targeted questions before producing anything, and to include a one-sentence rationale for every suggestion. That framing shaped the entire interaction model.
Phase 06 · Hours 38–46
Figma MCP + Claude Code
Claude Code connected to the Figma file via the MCP server integration. Rather than describing components from a screenshot, Claude fetched the actual node metadata: component properties, spacing values, layout constraints, and typography settings. Each React component was implemented directly from the live spec.
The visual output matched the Figma design without manual translation. Spacing came from the component, not from estimation. Colours came from the tokens, not from eyeballing. This was the phase that made the "design-to-code gap" feel like a solved problem rather than a friction point.
Phase 07 · Hours 46–50
Build sprint and production deploy
The final sprint used Cursor and Vite's hot module replacement to keep the iteration loop tight. A change in code appeared in the browser within two seconds. Edge cases, loading states, and error handling were worked through in real time rather than in a separate QA pass. The Vercel deployment took under two minutes. The app went live with three working API integrations, mobile-responsive layouts, and a production URL. Fifty hours in, Roam was a real thing that worked.
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.
01
No AI-native planning layer
Booking platforms bolt AI on top of existing search UIs. The question was whether you could design the planning layer as an AI-first conversation from the start, not as 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 view with cost estimates doesn't exist as a lightweight standalone tool.
What's built
What made it into the 50 hours
01
Trip brief
Destination input, traveller count, date range, budget tier, transport preferences, and activity interests. Fully interactive, feeds directly into the AI generation prompt.
02
AI itinerary generation
Day-by-day itinerary powered by the Anthropic API. Brief inputs are injected as hard constraints. Output includes time blocks, activity cards, cost estimates, and AI-written reasoning notes per suggestion.
03
Accommodation picker
Three AI-suggested options filtered by budget tier. Live nightly rates pulled from the Xotelo API. Each option includes name, location, price, and a short rationale.
04
Location data via Google Places
Restaurant and activity suggestions are validated against the Places API. Real location names, not hallucinated ones. The API call happens in the background during itinerary generation.
05
Mobile-responsive layout
All screens are responsive from the React/Vite build. The trip input form, itinerary view, and accommodation cards all adapt to mobile without a separate mobile design pass.
Reflection
What 50 hours teaches you about building
The constraint forced clarity that open-ended projects rarely produce. A few things stood out as more valuable than expected:
Core build stack
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.
The Figma MCP changes the design-to-build relationship.
When Claude Code can read live node data from the Figma file directly, the translation layer between design intent and code disappears. You're not describing what you designed; the tool reads it. That's a qualitatively different workflow, not
Tool chain sequencing matters as much as tool selection.
Each tool in the chain produced an output that the next one consumed. Figma Make's wireframes shaped what Figma Agent populated. The tokens export shaped what Claude Code implemented. Getting the sequence right meant each tool operated on well-formed input rather than compensating for gaps.
Scope decisions are design decisions.
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. The 50-hour ceiling made those calls fast and unambiguous.
Conclusion
What this proved
Roam isn't finished. A production version would need a proper backend, user accounts, saved itineraries, real booking integrations, a cost-splitting module for group trips, and proper map routing. There's a meaningful product to build here.
But 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 50 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.
That's the shift worth documenting.