Engagement
Readers finished a post and left. There was nothing to act on, so the blog collected attention and spent none of it.
From travel content to working AI planning tools.
I designed and built CityCaster and SlopeCaster, from UX/UI and front end to structured data, AI itineraries and scheduled automations. A connected travel platform powered by Claude Code, Supabase, OpenAI and n8n.
- Products
- CityCaster · SlopeCaster
- Role
- AI Product Builder · UX/UI
- Duration
- 2026
- Tools
- Figma, Claude Code, Supabase, OpenAI, n8n
The challenge
A blog can tell you where to go. It cannot plan the trip.
Travel content inspired readers but left the practical planning to them. CityCaster and SlopeCaster needed to connect places, budgets and current conditions in a journey people could act on, with reliable data behind the AI-generated plan.
Trust
Generated plans are easy to produce and easy to disbelieve. One closed museum, and the reader stops trusting the rest.
Clarity
A trip has a hundred variables. Showing them all is honest and useless, so each product picks what matters first.
Process
Design, build and automate in one workflow.
I owned the complete product loop: define the experience, build the interface, connect the data and keep the service running.
-
Wireframes
Mapped the planning flows in Figma, using trips we had taken to check which decisions a traveller needed to make first. The wireframes gave both products a shared starting point.
-
Visual design
Created a shared UI for place cards, maps and planning. CityCaster focuses on stays and budgets; SlopeCaster on snow and lift conditions. Consistent components keep the experience connected.
-
Build
Built the front end with Claude Code, connected Supabase for structured data and used OpenAI for itinerary generation. I checked design decisions in the working interface as I built.
-
Keeping it live
Connected n8n to refresh weather and snow conditions on a schedule. I also wrote the content and managed the social channels, connecting the product with the audience it serves.
Key decisions
The reasoning behind the work.
I connected product design, working code, data and automation in one delivery process. The priority was a useful plan supported by real information, with an interface that made the next decision clear.
-
Structured data before generated text
Itineraries are generated from a schema of real places, costs and opening hours held in Supabase, so OpenAI arranges facts it was handed instead of inventing them. Structured data is slow to gather and caps how surprising a suggestion can be.
-
One system, two products
One card serves both products: a photo, a label, a name and three rows of numbers. CityCaster fills them with nights, budget and what a city is best for; SlopeCaster with temperature, wind and snow. A shared component means a change that suits one product has to be good enough for the other, and sometimes neither gets the best answer.
-
Built it instead of specifying it
I used Claude Code to turn the Figma design into a working CityCaster interface, checking the cards, map and trip-planner entry point in the browser as I built. Working directly on the product let me resolve design details in context. It also made testing and maintaining the code my responsibility.
-
Automations over maintenance
n8n refreshes weather and snow data on a schedule, normalizes the readings and updates the records behind CityCaster and SlopeCaster. The cards turn those readings into useful conditions. A broken feed can leave plausible-looking values behind, so freshness matters as much as the automation.
Results
Live, and still mine to run.
- 1
- Person, from first sketch to deploy
- 25
- Cities mapped, each with its own budget
- 5
- Tools in the product stack
- 2
- Live products, with BeachCaster next
Travalera runs on a stack I chose and can change: Figma for design, Claude Code for the front end, Supabase for the data, OpenAI for itineraries, n8n for the automations. The blog and the social accounts are mine too, so nothing here waits on anyone else.
These describe what was built, not how it has performed. Usage numbers are not in yet.
Reflection
Building the product made design, data and maintenance part of the same responsibility.
Next, I would improve place-data coverage before expanding itinerary generation. The first version showed how plausible AI output can hide gaps in the underlying records.