CityBites

A hobby app that builds each day around where you want to eat, then routes the rest of the trip to match.

My role: Product Design, Engineering
Team: Sole designer and engineer
When: 2026 · 2 months
Platforms: iOS, Android, Website

Visit CityBites’s website, opens in a new tab

shipped to both stores: iOS + Android

The 30-second version

Problem: Planning a food trip meant juggling reviews, map pins and a spreadsheet, then checking hours and distances.
What I did: Designed and built native iOS and Android apps, with code checking the constraints and Claude making taste judgments.
Result: Live on the App Store and Google Play, with timed daily itineraries and OpenTable booking.

Context and constraints

CityBites is a travel planner that starts with where you want to eat. Each day is built around restaurants and cafes, and nearby sights, neighborhoods, and walking routes get fitted in around them, based on your cuisines, diet, budget, and the kind of trip you're after. It runs on Firebase, the Google Places API, Apple MapKit, and Claude.

My role and the team

Just me. I designed the product and its design system, CBDS, in Figma. I wrote the iOS app in SwiftUI and the Android app in Kotlin, and built the itinerary backend on Firebase, the Google Places API, Apple MapKit, and Claude.

The problem

When I travel, I plan around where I want to eat, and doing that means juggling review sites, saved map pins, Instagram posts, and a spreadsheet. Then you still have to work out opening hours and how far apart everything is. On a short trip that's a lot of time spent planning instead of eating, and it's easy to end up zig-zagging across a city.

Key decisions

01 / 02

Code checks the constraints

The call: Use code for opening hours, meal fit and filtering out chains. Let Claude choose places and judge taste.
Why: Opening hours cannot be wrong. Claude is useful for judgment calls about what someone would like.

02 / 02

Return a day people can follow

The call: Build a timed itinerary around meals, with nearby stops and clustered routes.
Why: A list of places still leaves the planning to the traveler. Distance, transport and clustering keep the day from zig-zagging.

The work

CityBites Explore screen with foodie cities and trip-type filters — Explore. You start from a craving or a city.

CityBites Food Preferences screen with flavor, dietary, and budget options — Setting your tastes: flavors, dietary needs, and budget, which the planner treats as constraints.

CityBites map showing a numbered, clustered walking route through a city — The route comes from rules in code. Distance, walking or driving, and clustering stop the day from zig-zagging across town.

CityBites day-by-day itinerary with timed stops and travel times between them — The plan: a timed day built around your meals, with a reason for each stop.

CityBites OpenTable hand-off screen for booking a table — Booking through OpenTable without leaving the app.

How it scaled

The itinerary backend uses Firebase, Google Places, MapKit and Claude. Rules in code check the constraints before the plan is returned.

Results

I built it on my own and shipped it to the App Store and Google Play. Claude runs the itinerary engine.

shipped to both stores: iOS + Android

Reflection

I started this to see whether an AI could plan a trip day by day. It works, but only with a lot of structure around it. Claude is good at taste, and I wouldn't trust it with opening hours. What's left now is curation, getting the picks consistently good.