Skip to content
9x Dev
All case studies
Case study

A City Guide That Rebuilds Itself Around Where You Land

Pick a city and the whole app changes: the map, the categories, what it recommends for tonight. We took a travel startup from a clickable prototype to both app stores in eight weeks.

Client
Travel startup
Industry
Travel and hospitality
Duration
8 weeks
Services
Mobile Apps, Product Design
The challenge

One App That Feels Different in Every City

Most travel apps are the same list of pins whichever city you open. The founders wanted the opposite: choose a city and the app becomes that city’s app, with its neighbourhoods, its transport, what's open on a Sunday, and the places locals would send a friend.

That meant an interface driven by city data instead of hard-coded screens, and accommodation, attractions and restaurants pulled from several providers into one consistent model. Two founders, a validated idea, a design in Figma, and no engineering team yet.

What we built

A Map-First App Driven by City Data

A native iOS and Android app where every screen is configured by the selected city, a places layer that merges and ranks data from multiple sources, and a trip planner that puts it all on one map.

1
City-aware shell. Navigation, categories, copy and map styling come from a per-city content model, so a new city launches with data, not an app release.
2
Unified places layer. Stays, sights and restaurants from several providers, deduplicated and ranked, with opening hours and prices refreshed on a schedule.
3
Trip planner. Save places into days, see them on the map in walking order, and keep using it offline once a city is downloaded.
Approach

Eight Weeks, One City at a Time

Eight weeks for two native apps isn't a heroic schedule. It's what AI-native engineering looks like in practice: the provider connectors, the data model and most of the test suite were generated with AI tooling and reviewed by senior engineers, so the team spent its time on the parts that needed judgment.

01Week 1

One city, on paper

A clickable prototype for a single city, put in front of travelers before we wrote a line of production code.

02Weeks 2–4

Data before screens

The city content model and the ingestion pipeline for three providers came first. The first build was a map with real places on it and nothing else.

03Weeks 5–6

The second city

Adding a second city with zero changes to the app was the acceptance test for the architecture. It took an afternoon of content work, not a sprint.

04Weeks 7–8

Store launch

Released on iOS and Android with analytics, crash reporting and a release pipeline, then handed over to the first in-house engineer we helped them hire.

Contact

Have an App That Needs to Ship on Both Stores?

Tell us what it should do, and an expert team member will reply.