The idea for Route Planner AI came about because I was fed up with the hassle of travelling from one city to another. As a game development student, I was constantly switching between different apps just to answer one simple question: what is the best way to get from A to B? Google Maps showed me one part of the journey, TomTom showed me another, and DB Navigator showed me the train route, but I still had to mentally piece everything together myself. That was the moment Route Planner AI stopped being a vague idea and became something I genuinely wanted to build.
What frustrated me most was not that the information did not exist. It was that the information was scattered. A route might look good by train, but only if I could reach the station quickly. A car route might seem faster at first, but only until parking became an issue. Sometimes, the smartest option was not purely car, train or walking. It was a mixed route involving a short drive to a station, followed by rail and a short final stretch on foot or micromobility. This kind of decision-making was exactly what I felt was missing from the tools I was using.
I'm not sure what to call this planner at the moment, so I'll just call it "Route Planner AI" — putting "AI" in the name is very cool and trendy right now!
So the first version of Route Planner AI was born from a very practical goal: I wanted a single place where I could find all of these options instead of having to compare them manually every single time.
Why did I want to build it?
I did not start this project because I wanted to clone a navigation app. I started it because I was tired of planning routes like a human middleware layer between several different services.
The core idea behind Route Planner AI was simple from the beginning:
- combine long-distance and local travel planning into one process;
- make intermodal travel seem normal rather than awkward;
- reduce the amount of manual comparison required to plan a realistic trip.
The last point mattered the most to me. I wanted the tool to think more like a real traveller. Not just 'Which train is next?', but also 'How do I get to that station?', 'Is it worth taking a scooter for the first stretch?', and 'Does this route still make sense when the last kilometre is inconvenient?'
From day one, I knew I didn't want Route Planner AI to become 'just another transit page'. The whole point was to connect the gaps between services.
The reason I used Replit for the first prototype was […]
I used Replit for the first prototype because I prioritised speed over perfection. I needed to move from 'an idea in my head' to 'something I can actually interact with' as quickly as possible. Replit was ideal for this kind of early-stage experimentation, especially as it allowed me to iterate quickly and utilise AI assistance practically rather than treating AI as a gimmick. Replit's official product positioning centres on turning prompts into apps and websites, which matched the rapid prototyping workflow I wanted for this phase. I am comfortable using AI tools as part of a real development workflow. Not as a replacement for technical understanding, but as a means of accelerating ideation, scaffolding and iteration when creating something from scratch.
As a Game Development student, this felt very natural to me. In game projects, I am accustomed to prototyping early on, testing ideas before they are refined, and getting something interactive on screen as quickly as possible. I approached Route Planner AI in the same way.
The first prototype was, to be honest, a rough prototype with a half-working backend and a much more convincing frontend.
That sounds harsher than it really was. The important thing is that the interface made the project feel real. I had a basic flow. I had an actual surface to react to. Rather than just discussing the concept of intermodal planning, I could now visualise where the origin and destination inputs would be located, how the results would be presented, and the type of route comparison experience I wanted the website to offer.
The front end was the first real milestone because it translated the project from concept to structure.
At that stage, the prototype gave me three useful things:
- a visible product direction;
- a much clearer sense of scope; and
- a better understanding of what the backend would actually need to support.
The last point was important. Once the interface existed, the hidden complexity became obvious very quickly. It's easy to say, 'I want one website that combines everything.' It's much harder to define what 'everything' actually means in technical terms.
What was not working yet?
The back end was only partly there on day one.
Some parts worked well enough to make the demo feel alive. Other parts were fragile, incomplete or simply not ready. There were still a lot of gaps between what I wanted the project to do and what it could reliably do. This was particularly evident in the underlying logic of combining different transport modes to produce a coherent result.
While the first version of Route Planner AI looked promising, it was very much a prototype rather than a finished product.
That was fine.
I think one of the easiest mistakes in write-ups of personal projects is to pretend that the first version was cleaner than it really was. Mine was not. The early version was messy in the same way that many real student projects are: exciting and functional in places, but broken in others. However, it was good enough to prove that the idea had value.
And that mattered more than polish.
This first step still mattered.
Even though the back end was only half functional, I still consider this to be the real beginning of Route Planner AI.
The reason is simple: once the interface existed, the project stopped being hypothetical.
I could point to something concrete and say, 'This is the problem I want to solve.' I could explain the user flow more clearly. I could identify where a map would be useful, where route summaries would be useful, and where different transport options would need to be compared. The prototype did not solve the hard routing logic yet, but it did achieve something else: it gave the project shape.
That is a big deal.
As a Game Development student, I tend to think in terms of systems, player flow, feedback loops and readability. A prototype does not need to be perfect to be useful. It just needs to be clear enough to test the underlying idea. In game development, you don't wait for every system to be finished before evaluating whether the core loop works. I approached Route Planner AI in the same way.
The first prototype answered one very important question for me:
Is this worth developing further?
The answer was yes.
The bigger vision behind Route Planner AI
From the outset, the goal was to reduce friction in real-world travel planning.
I wanted a website that could bring together the various elements I had to compare manually every time I travelled: long-distance rail, local access, alternative initial steps and final practical steps. Not in a theoretical 'smart city' way, but in a practical, student-oriented way. I just wanted the route planning experience to be less frustrating and more realistic.
This vision was present from day one, even if the implementation was nowhere near complete.
The first prototype was not the finished product. It proved that the idea deserved a proper build.
What comes next?
This first post is intentionally focused on the idea stage and the earliest prototype.
The deeper technical aspects, such as the backend architecture, route generation logic, first-mile and last-mile considerations, mixed transport strategies and messy data problems, came later. These are the things that make a routing project far more complex than it first appears.
I had the idea.
I identified the pain point.
I had built a basic interface with Replit.
There was just enough functionality to suggest that Route Planner AI could become a serious project.
That was enough for day one.
If you have ever had to plan a trip across Germany by manually comparing several apps and filling in the gaps yourself, you will understand exactly why I started building this.
