---

I'm building a tour guide that walks with you

Here's a scene you've probably lived. You're in a city you don't know, standing in a square that is clearly important. There's a statue, a church, and a building with a plaque you can't read. You get your phone out, search the name, open Wikipedia and start scrolling. Five minutes later you've read two paragraphs about the architect's early career and still don't know why the statue is there. Your friends have moved on.

The alternatives aren't great either. A group tour runs at 10:00 and lasts three hours, whether or not you care about Baroque churches. An audio guide gives everyone the same 40 stops in the same order. A guidebook is great the evening before and useless while you walk.

What I wanted was simpler: tell something what I'm into and how much time I have, put the phone in my pocket, and have someone tell me the story of each place as I reach it.

So for the last eight weeks I've been building it. It's called Guided Tours.

What it does

You open the app in a city and answer three questions:

• What are you into? History, architecture, food, culture, local life, hidden gems, nature, photography, weird & unusual, or the famous landmarks. Pick a few.

• How much time do you have? An hour, two, an afternoon, or a whole day.

• Where are you starting? Usually where you're standing right now.

The app builds a walking route through places that match, in an order that makes sense on foot, sized to the time you gave it. A history-and-architecture tour of Kraków and a food-and-local-life tour of Kraków share almost nothing.

Then you walk. When you reach a stop, the narration starts on its own. You don't tap anything or look at the screen, and the phone stays in your pocket with AirPods in. Between stops it tells you about the walk to the next one and gives you a nudge on long legs. When you finish you get a map of your walk and an offer of another tour from where you're standing.

If you'd rather not build anything, there are ready-made tours too. Pick one and go.

The whole tour works offline once it's downloaded, which matters more than I expected. Roaming data, old-town signal and a phone at 15% battery are where most travel apps quietly fall apart.

The rule I keep coming back to

Early on I wrote one line into the project brief that has settled more arguments than anything else:

It is not an AI travel planner and not a chatbot for tourists. It is a personal tour guide that accompanies you while you explore.

There's an LLM behind it, of course. It picks places for your interests and turns source material into something worth listening to. But you never see a prompt, never chat with anything, and never wait for a model while you stand on a street corner. All the AI work happens before you start walking. During the walk the app is a GPS, an audio player and a downloaded bundle.

That rule shapes a lot of decisions. Two examples:

Stories are generated once per place, not once per tour. A narration for Wrocław's Market Square is written, checked and turned into audio once per language. After that, every tour that passes the square reuses it. Generating a personalised tour mostly means choosing and ordering places, which is cheap. Expensive work is spread across every user who ever walks past that place, and that's how the cost per tour stays well under €1.

Accuracy is a gate, not a nice-to-have. A tour guide who gets facts wrong loses you at the second stop. Every place in the catalogue comes from real sources: OpenStreetMap for where it is and what it is, Wikidata for structured facts, Wikipedia for the narrative. The narration can only state things it can trace back to those sources. Before any audio is recorded, a separate verification pass checks each claim against the source record and rejects the narration if something doesn't hold up. A place without enough sourced material simply doesn't get narrated. I'd rather have a thinner tour than a confident fabrication.

Under the hood (briefly)

This is a dev blog, so here's the short version of the stack. Each piece probably deserves its own post.

iOS: native Swift and SwiftUI. This was never going to be a cross-platform app. The product is the platform features: Core Location waking the app when you arrive near a stop, even when it's suspended; AVAudioSession with .playback and .spokenAudio so narration keeps going with the screen locked and ducks your music instead of killing it; a Live Activity on the Lock Screen; GRDB for the offline tour bundle.

Backend: NestJS, PostgreSQL with PostGIS, BullMQ. It's split into domain modules (POIs, ingestion, tours, narration, routing) so that adding a city means running a pipeline, not writing code. Everything slow or expensive (ingestion, generation, verification, text-to-speech) runs as queued jobs.

Data ingestion is automated. A new city starts as a curated list of its top sights, which gets resolved to OpenStreetMap and Wikidata entries, imported, enriched, narrated in English, voiced and published. Each step that spends money or makes something public waits for my approval in a small back-office.

Infrastructure: one droplet running Docker Compose. I'm one person and I'd like to sleep at night, so no Kubernetes. A few of the "self-host everything" decisions from week one have since been reversed, and I'll write those up separately.

Where it is today

The first commit was on 12 August 2026. Eight weeks and about 4,000 commits later:

• 30 cities are live, from Wrocław, where it started, to Rome, Paris, Lisbon, Vienna, Barcelona, Edinburgh and more.

• Narration is in English and Polish.

• The app is in a TestFlight beta. It's free while it's in beta.

The original plan said "one city, done well, before any others." Wrocław was the test bed: I walked its tours myself with the phone in my pocket, checking that narration started at the right corner and audio survived a locked screen. The second city was where I learned whether "adding a city is a pipeline run" was actually true. It mostly was, and once onboarding became an operations task instead of an engineering task, the count went up quickly.

The number I watch isn't downloads or signups. It's completed tours per generated tour. If people finish a walk and immediately ask "what else can I see?", the product works. If they drop off at stop three, no amount of cities will fix it.

Being a solo founder with a lot of help

I'll be honest about how one person ships this much in eight weeks. Most of the code is written by AI coding agents, with me as the person who decides what gets built, reviews it and walks the tours. That deserves its own post, because it's less magic and more process than people assume. Short version: planning documents, small phases, reviews after every phase, and being strict about what an agent is allowed to touch.

The less glamorous part is cost. I'm paying for every token and every second of generated audio myself, so a whole milestone went into making waste impossible: no retrying a request that will fail the same way twice, cheaper reasoning for mechanical calls, and every API call logged with its price. Onboarding a city is now a known, small number.

What's next

More posts on the parts that turned out to be interesting:

• why I self-hosted my routing engine, then stopped a few weeks later

• how the fact-checking pass works, and what it still gets wrong

• what eight weeks of building with coding agents actually looked like

And if you're travelling soon and have an iPhone, I'd love for you to try it. Pick a city, give it an hour, and tell me where it went wrong. Early access is at guidedtours.app.