The map view loads slowly. A map on which exactly this task has been solved. The orange-glowing sunset The background shimmers in shades of black-green, slow animations drifting across it with a hypnotic kind of patience. A map, two markers, and somewhere in the middle a third one, that...

...hold on, I’ll be back in a minute.

Let me start over.

A few weeks ago I was sitting at the foot of a loess wall, somewhere past Császártöltés on the Hungarian Great Plain Blue Trail, around 5 in the afternoon. Phone in my hand, in my head a complete railway timetable trying to optimize itself. An hour and a half, and I make it to Pincefalu in a hurry. From there a bus runs to Baja. That’s the good news, but there is bad news too: my accommodation is in Kiskunhalas. You can get there from Baja, in fact these days you can only get there through Baja - provided I actually make it by half past six.

Picture: on the Great Plain Blue Trail, heading toward Kunfehértó

A Sunday in this timetable looks like someone designed it as a complicated game of chance. A moment ago the theme was the soft light filtering through the trees, the play of vineyard shadows. Now it is just buses. The last three kilometers of the hike pass with phone-tapping and stress, and a bit of running. I could be running at home too.

On the Camino, this kind of question never even came up. A road on which the pilgrim only walks forward, albergue in the evening, onward in the morning, and somewhere at the very end an ocean. But on ordinary days the hike has to draw a circle somehow. You have to return somewhere, somehow. To where I left the car. To where the train home departs from. To where the accommodation is.

And if the two endpoints of the route are not close to each other, then a third one needs to be found. An origin point.

What happened at the foot of the loess wall is that, because of all this, a product development began. Yes, story-based. Which I then told to an AI back at home. Who asked back, quite good things. What does “late” mean? What does “bad connection” mean? Has it happened before? Always. Well then, this is a pattern.

So there is an everyday experience, a story. A frustration, a question.

Then out of this comes a conversation. With myself (during a hike there is time for this), with the artificial intelligence, with others. This conversation, if it ripens, gives birth to the second story, the story of product development.

And this, if I do it well, transforms into a third story, which the product tells to the user. Not “this here is a base point”, but rather: this is the place you are looking for, because here you can leave the car, next to it there is a shop where you can buy a sandwich, on the way back you’ll have to wait 30 minutes, but luckily this is where the village’s best gyros place is, it’ll be open, go in.

And from this comes the fourth story, the one that matters: the story of the user’s hike.

The answering of this question became the Hikebase, one of the sub-stories of Roamr. An app within the app, that searches for the best answer to a single question: where to leave the car.

For this, at some point, you need code. And a server. And the code always begins with a formal question, because the machine - whatever we think of it nowadays - computes, it does not narrate.

So let’s get the math out of the way. The starting point of classical route planning: given a graph G = (V, E), with nodes (V) being the stops and edges (E) the connections between them. But since “at seven in the morning different edges are alive than at ten at night”, and so on, what we are really talking about is a time-dependent graph: G = (V, E, w_t), where every edge e ∈ E has a weight function w_t(e), giving the travel time and accessibility as a function of the departure time t (w_t(e) = ∞ if that connection does not run at time t).

The weight, however, is not a scalar, but a vector: w(e, t) = (time, distance, elevation gain, difficulty, experience, risk, …). The user’s preferences are encoded in a preference vector p, and the actual edge cost is their scalar product: c(e, t) = ⟨p(t), w(e, t)⟩. The p itself is also time-of-day dependent - in the morning speed might dominate, around noon something like shade, at dusk a stop close to the descent.

The time of walking sections is not linear in distance either: we approximate it with Tobler’s hiking function, v(s) = 6·exp(−3.5·|s + 0.05|) km/h, where s is the signed slope - meaning that beyond a certain point even going downhill slows you down.

So the task is not simple Dijkstra, but a constrained, multi-criteria, time-dependent shortest-path search:

min Σᵢ c(eᵢ, tᵢ)
s.t. Σᵢ time(eᵢ, tᵢ) ≤ T_max (e.g. back before dark)
maxᵢ difficulty(eᵢ) ≤ D_user
tᵢ₊₁ = tᵢ + time(eᵢ, tᵢ) (time chaining: the weight of the next edge depends on when I get there)

... and so on. But more about this in the coming entries.

And here we come back to the topic of the opening sentence: this is a classic facility location problem - a variant of the task used in logistics for placing warehouses. Given the traffic, you look for an intermediate point that minimizes the round-trip cost. The big ones, like Conveyal, solve exactly this kind of problem for cities - only they optimize the journeys of millions of people, while we are now optimizing where to leave the car tomorrow.

And this is where I am now, after a net one day of AI-based development (with Claude Code). What this actually means, I will be writing about a lot in the coming entries. Yes, the UI is still chaotic, scaffolding everywhere. But on this map I can already see a bus stop where, yes, I really would leave the car if I were heading out tomorrow.

Picture: the current state of Hikebase. That big blue dot in the middle is the selected base.

A practical note to close with. While the Hikebase is being built, there is a usable enough trick in Google Maps for similar situations: in the public transport route planner, by toggling between “depart at” and “arrive by”, you can also calculate backwards. With a few attempts you can sketch out the place that lies in the middle of the car-accommodation-train triangle. It is not pretty, it is slow, but I too did it this way for years. Now, however, the Hikebase gives it to me within seconds. I hope soon to you as well.

If anyone has a similar, regularly returning frustration during hiking - something about which you always tell yourself “I’ll solve this somehow one day” - I’d be glad to read it. It will not only be the Hikebase that gets built into Roamr, you know.

Saint-Jean-Pied-de-Port, the morning I first put on the backpack for the Camino.

I did this once before, ten years ago. Back then with an EU grant, an office, colleagues, a business plan, and the kind of attitude where sure, failure is important because you can learn from it, and so on. But I’d rather stay unlearned, since I won’t be the one going down with this. That project went its own way, straight into the ditch, and I went mine. I didn’t stay unlearned... and now, ten years later, the same kind of idea is in front of me again, only everything around it has changed. I’m alone. There’s no office. And the code we’re going to write, most of it won’t be written by me. In fact, not even by a human.

Before I dive in, let me set one thing straight, because this is what the whole series is going to live or die on: this is not a dev blog. There won’t be code snippets and architecture diagrams here. Well, there will be, but those won’t be the point. The point is the story. How an app gets built when you spend hours every day talking to an AI, mostly on weekends and in the evenings, since during the day the focus is on earning the daily bread.

I have a phrase for this that I came up with along the way, and it’s possible someone else thought of it before me: story-based development. It came from noticing what I’m actually doing. Working with an AI isn’t coding. Vibe, maybe, but coding, no. It’s a conversation. I describe what I want, it asks back, suggests, we argue, and the picture in my head shifts along the way. This conversation has an arc, it has turning points, it has nerve-grinding stretches and moments where I lean back in my chair, or fall flat next to it. Every feature is a scene. Every refactor is a rewritten chapter.

And if that’s true, then what we’re building isn’t just an app. It’s a novel, whose end product happens to run on iOS and Android.

The novel is called Roamr. The authors are me and an AI. The reader will be you.

A few words about myself, since some is owed: my name is Zsolt, I live in Solymár, in one of its prettier parts. A village, I think, next to Budapest, where in the mornings even the neighbour’s rooster stays quiet, the silence is that big. I’m a theoretical physicist, I have a paper to prove it, but I left that path sometime in the early two thousands and drifted into software. Whether that was a good decision, I still don’t have an answer to. Maybe I won’t have one by the end of this series either. What’s certain is that something stayed with me from physics that’s coming in handy now: the belief that behind every complicated thing there’s a simpler layer worth scratching at, only to find out that this layer is also bloody complicated, but there must be something simpler behind it.

We start around tomorrow. I still don’t know what the app is going to do beyond being called Roamr. I have hunches, and a few trail markers. I don’t know either if I’ll get anywhere with it. What I do know is that I’ll write down how it happens. The good calls and the dumb dead ends, the AI’s small wonders, and the moments when I drive the laptop into the monitor with the keyboard, preferably right where I can see the Claude logo.

If something comes of this, you’ll be able to say you were here from the start. If nothing comes of it, that’s also a story, and you were here at the start of that too.

Sit down. Let the mechanical keys clack. Let’s begin.