The problem

Flights, hotels, cars and destinations each live behind their own search box — and the traveller is left to be the integration layer.

Planning a trip means twelve tabs, a spreadsheet, and a lot of copy-paste, because no tool treats the trip itself as the thing you're building — only the individual bookings. Andacity is discovery-first: you plan the trip, and the destinations, hotels, flights and cars assemble around it, as one object you can save, share and come back to.

What I built

A search mode per vertical destinations, hotels, flights and cars — each tuned to how you actually shop for it, but sharing one result / entity / trip grammar so nothing feels bolted on.
The trip as a first-class object add-to-trip from anywhere; the trip persists, revalidates, and holds the whole plan together instead of scattering it across bookings.
Shareable, canonical routes every search, place and trip has a clean URL that survives being sent to someone — the plan travels with the link.
Entity resolution across verticals one canonical identity for a place, hotel or airport everywhere in the app, so results line up instead of contradicting each other.
Guided booking with a trust panel a booking surface that shows what is happening and why, rather than a black-box checkout.
Edge-rendered, run by one person Qwik/QwikCity on Cloudflare over a Fastify + Postgres core — fast enough to feel instant, small enough to operate solo.

The interface

Hard crops of the real thing at poster scale — the product as it actually looks, not a browser-chrome mockup.

Andacity Hard crop · UI

4travel verticals unified — destinations, hotels, flights, cars

0tabs and spreadsheets to plan a trip

1engineer, from the edge render to the database

Andacity is live at andacity.com (v0.6.0) and still moving fast — real usage and conversion numbers replace these as it grows.

Andacity

The problem

What I built

The interface

Engineering

Message sent.