I've been working on a side project called mapv.io, and I thought this would be a good place to share how it came about and some of the problems I ran into while building it.
I'm a software developer by profession, but travel planning is one of those things I tend to overthink a little.
The way I normally plan a trip is pretty simple at first:
I find somewhere I want to go, buy the flights, start collecting places I want to see and things I want to do, then ask ChatGPT or Claude to turn all of that into an itinerary.
And honestly, that part works surprisingly well. The problem starts afterwards.
I then end up manually checking everything:
- Is this actually the right route?
- Can I realistically drive from here to there in that amount of time?
- Does this attraction fit before the next booking?
- Now that I've booked this hotel, does the itinerary still make sense?
- If I move one thing, what else does that break?
- Am I ending the day somewhere sensible for tomorrow morning?
Quite often I'd change a hotel, add a reservation, discover something new I wanted to do, or move a stop to another day, and then have to mentally re-check a large part of the trip again.
That was really where the idea started.
There are already some pretty good travel planners
I definitely wasn't starting from the idea that nothing useful existed.
There are already services that do parts of this very well.
One I used was excellent at visualising a trip. You added the cities you were visiting and it produced a really nice route and visual overview. I genuinely liked that part.
But the planning side was very light. It wasn't really checking whether the day itself worked. It was mostly visualising the trip I'd already decided on.
Another planner I tried went much further in the opposite direction. It had a lot of planning functionality, but for me it became a bit overwhelming, the finished trip wasn't particularly visual, and I still found myself manually checking quite a few of the constraints I cared about.
I also tried several AI itinerary generators.
They're great for ideas and getting a first draft quickly, but I kept coming back to the same problem:
generating an itinerary and validating an itinerary are two different things.
None of the tools I tried quite covered the combination I personally wanted, so I started experimenting with my own.
That slowly became mapv.io.
The basic idea
I didn't really want another tool where AI writes a nice-looking list of places.
I wanted the map, itinerary, bookings, routes and constraints to all describe the same trip.
So instead of:
Generate itinerary → assume it's correct
the idea became closer to:
Build itinerary → route it → check it → show what's questionable → let the user decide
AI is still useful. I use it myself constantly.
I just don't want its answer to automatically become the source of truth.
Some of the cases that became more interesting than I expected
A simple overlap like two reservations at the same time is easy.
The annoying cases are usually the ones where every item looks valid when you inspect it individually.
"It's open" doesn't necessarily mean you can visit it
Suppose an attraction is open until 18:00.
Your itinerary gets you there at 17:20, so at first glance everything looks fine.
But if its last admission is at 17:00, the plan is already broken.
This sounds obvious when written down, but it is exactly the kind of detail that's easy to miss when looking at a long itinerary.
A booking can break things several stops away
A fixed reservation at 15:00 might be completely valid.
But perhaps the route you've built naturally moves east throughout the day, while that booking suddenly pulls you 40 minutes back west.
Now the reservation itself isn't wrong, and nothing overlaps, but everything around it starts becoming inefficient.
That made me think much more about the difference between detecting a hard error and saying:
"This is technically possible, but you probably don't want to do it this way."
That distinction became important throughout the app.
Changing the hotel can quietly change the whole trip
This one comes directly from how I personally plan.
I'll often create most of an itinerary first and only book accommodation afterwards.
Then maybe I find a better hotel 40 minutes away, change it, and suddenly:
- the end of Day 2 is much worse
- Day 3 starts in the wrong direction
- something that previously fit before a reservation no longer does
- a nice route now involves driving backwards
The individual activities haven't changed.
Only one accommodation changed.
But the structure around it has.
That pushed me toward treating overnight locations as part of the actual route rather than just information attached to a day.
Two good days can make a bad trip
You can create a perfectly reasonable Day 1 and a perfectly reasonable Day 2.
But if the accommodation between them is in the wrong place, you may end Day 1 with a huge drive and then drive most of the way back again the next morning.
Nothing on either day is technically invalid.
The transition between the days is the problem.
That pushed the planner toward checking the trip as a sequence rather than treating each day as an isolated list.
Travel time isn't just B - A
Connections were another rabbit hole.
An itinerary might say:
- activity ends at 13:00
- next reservation starts at 14:00
- the drive is 45 minutes
Looks possible.
But real travel often includes things around that route:
- getting back to the car
- parking
- walking from parking
- transfers
- some buffer for a fixed departure
- possibly returning a rental car or getting through a station/airport
I don't think software should pretend it can predict all of that perfectly.
What it can do is make those assumptions visible and point out when there isn't much room left for reality.
Weather became more useful when attached to time
"Rain on Tuesday" isn't particularly useful for planning.
What matters more is something like:
You have a viewpoint or hike at 14:30, and conditions around that period don't look great.
I didn't want weather to become another giant panel users had to interpret, so I ended up trying to keep it contextual to the actual itinerary.
One surprisingly difficult part: not warning about everything
This was probably one of the more important product lessons for me.
Once you start writing validation rules, it becomes very easy to make the app incredibly annoying.
Almost anything can theoretically be a problem:
- a tight schedule
- a long drive
- bad weather
- no meal break
- a late arrival
- an unusual route
- a missing accommodation
- opening hours that may be stale
But if every day has eight warnings, users stop reading them.
So I've spent quite a bit of time trying to separate:
Things that are actually broken
from
Things that are unusual enough that the user may want to check them
and from
Things the user probably already knows and doesn't need software complaining about.
I'm still refining this.
I also didn't want the result to feel like a spreadsheet
This was the other half of the project.
Some planning tools I've used are very capable, but by the time the trip is finished I don't particularly enjoy looking at it.
On the other side, I've used apps that make trips look really nice afterwards, but I wished they had much deeper planning tools beforehand.
I wanted to see how close I could get to doing both.
So the trip has an overview map and visualisation rather than the itinerary existing purely as rows of data.
I'm also working on the shareable/video side of this, because I like the idea that something useful during planning can become something worth keeping or sharing after the trip.
The UI was another learning process
The first versions tried to show too much.
Maps naturally encourage adding more layers, controls, markers and information.
Trip planning does the same thing.
Eventually you can end up with a technically powerful interface that feels exhausting before the user has even added their first stop.
I've been gradually removing things, hiding less-important controls until they're needed, simplifying the itinerary, and trying to make warnings useful without dominating the screen.
The mobile version has probably made this even more obvious.
A map, timeline, day selector, controls and itinerary all competing for a 400px-wide screen forces you to decide what actually matters.
Where it is now
mapv.io is fully usable now, although I still consider it early.
You can build trips manually or with AI assistance, work directly with the itinerary and map, add bookings and fixed plans, route between stops, and have the planner point out problems it finds.
For me, the useful workflow is still very similar to how I planned trips before:
find somewhere → collect things I want to do → get help putting together an itinerary → refine it.
The difference is that I don't then want to spend the next few hours manually checking every change against maps, bookings, hotels, opening times and the rest of the trip.
The goal isn't for mapv.io to tell you:
"This is the perfect trip."
I'd rather it say:
"Here's the plan you made, here's the real-world information I can check, and here are the parts I'd take another look at."
There's still a lot I want to improve, especially around unusual trips and situations I haven't encountered myself.
I'd be interested in the weird cases
The project is mapv.io if anyone wants to have a look.
More than anything, I'd be interested in hearing about edge cases from people who have built scheduling/routing software, or from people who simply plan trips in far too much detail like I do.
If you've ever had an itinerary fail for a reason that a planner really should have been able to notice beforehand, I'd love to hear what happened.
There are almost certainly cases I haven't thought of yet.
Top comments (0)