← All projects

Atlas / Travel intelligence

A trip is more than an itinerary.

The interesting questions start after “where should I go?” Which visa applies? What train connects these stops? What should I know before I arrive?

Live product

A question worth building for
“Three days in Rome. What should I see—and what am I missing?”
Entry requirementsTrains & connectionsLocal context

Illustrative scenario

The spark

I wanted the practical details to travel with the plan.

Travel planning spreads one decision across maps, transport sites, entry rules, recommendations, and personal notes. I built Atlas to bring those questions into the same conversation as the itinerary: entry requirements, rail connections, local facts, community context, hot spots, and practical caveats.

Atlas · A trip in context
Atlas’s public Rome itinerary with destination photography and trip details
Actual Atlas interface · Explore Atlas ↗
Under the surface

From a travel question to a usable plan.

Explore the decisions behind the journey.

01 / Understand

Ask for the missing constraint.

A destination alone does not identify the relevant entry requirements. Passport and trip context matter. Atlas supports clarification before continuing visa and document questions.

Decision: clarify before personalizing.

02 / Ground

Keep the answer connected to the trip.

Trip Q&A uses saved trip, city, and activity context plus knowledge lookup, then a small summarization step. A question about the trip does not need to regenerate the itinerary.

Decision: separate answering from editing.

03 / Plan

Change the requested part.

Typed patches use the same reducer actions as the interface. Obvious moves and removals are deterministic; fuzzy edits use a scoped model call. New named venues must come from the user, the current trip, or verified candidates.

Decision: constrain what a model can change.

04 / Reuse

Share knowledge, preserve personal choices.

Reusable city slices are keyed by destination, trip shape, and venue data. Dates, pace, budget, and pins are adapted locally. Personalized results never flow back into the shared cache.

Decision: cache the reusable work, not the traveler.

The hard part

A small edit can break a whole trip.

Changing one activity can introduce a venue from the wrong city, overwrite another day, or make a connection infeasible. I scoped regeneration to the requested days, checked venue provenance, and marked affected parts for explicit refresh when feasibility changes.

Freshness has a cost. Atlas keeps last-known metadata while refreshing it, and gates shared itinerary caches on geography, venue eligibility, density, and duplication. A fallback can serve a request without becoming reusable truth.

In practice

15,600+ chat sessions

4,200+ itineraries · 5,400+ refinements
Atlas product usage · 28 days, Sep–Oct 2026.

Next.js · TypeScript · PostgreSQL · Vercel · AWS