Why Google & Apple Maps don't work
Picking the right exit when you are road-tripping is not a solved problem. The "Add Stop" functionality on Apple is frustrating, often-times wrong, and has no option for rest areas. I've noticed the "Add Stop" options are not holistic - they are just a smattering of options at exits ahead. Google Maps and Apple Maps on the phone are great when you are doing a radial search, but you don't care about the options that are near "as the crow flies" but far in terms of detour time. You want "1 minute off the exit for the next 5 exits" options.
A solved problem, re-solved in an app
That's where Pike comes in. With Pike, you can swipe through the next exits and look at the options at a glance via exit cards that are reminiscent of the famous blue logo signs you've undoubtedly used on the interstate before. Every option is within 5 minutes driving time of the exit. I love the simplicity of logo signs - it's why we generally rely on those over my wife searching on her phone. It's not that important of a decision and trying to Minority Report the next three exits on your phone for the right stop is not ideal.
Who is this for?
Well, my wife and I plan on going on a 6 week roadtrip starting in May, and we'll be doing a heck of a lot of driving on the interstate. She and I have similar tastes in food, but we have definitely made the mistake of waiting too long for an exit, getting hangry, and then ultimately stopping somewhere neither of us are crazy about.
I'm trying to make shopping for where to eat next easy to do. Maybe you're not terribly hungry right now, but wouldn't you want to know you're about to pass the last Chik-fil-A for 300 miles?
But also, we'll be traveling with two golden retrievers: Goose & Peanut. My app doesn't offer this feature just yet, but soon I will add parks and dog parks to the categories on the app. We like to let the dogs stretch their legs and RUN on a big travel day. This is a real problem we have, trying to track down a good place to let them loose, so I will be very much incentivized to get it right.
How did I build it?
Same as I've built everything these past several months. With Claude & Codex. This time I went in with no spec and no idea how map data actually works. I'd like to share early iterations and why they were wrong and briefly explain how I fixed them:
v1 - Directional Points of Interest (POIs)
The first iteration was basically "find restaurants that are ahead in my current direction of travel". What a terrible idea.
Why it didn't work
Roads, even interstates, have curves. As your car is driving, "restaurants in your general direction" will change over time and be inaccurate.
v2 - Non-directed interstate graph
Second iteration was to pull interstate data from OpenStreetMaps (OSM) and build a non-directed graph of the interstates. First, the app latches you to the closest edge of the graph and then traverses the graph in your current direction of travel via Dijkstra's algorithm to find upcoming exits. When I found an exit, I would do a radial search for POIs.
Why it didn't work
Because the graph was non-directed, it would encounter exits that are inaccessible to the user's current bearing via Dijkstra's. e.g. it would recommend the westbound rest area while you are traveling eastbound.
v3 - Directed graph for every direction
Third iteration was to solve the inaccessible exits by creating a directed graph for both directions of travel. At this point I'm face-palming thinking to myself - "If I has just stopped to think about this problem even just a little bit, I wouldn't be having to rework this so much." Does that remind you of a product manager you once worked with who had a skinny spec?
Why it didn't work
Well, it did kinda work, but the problem is, OSM data is quite messy, and traversing graphs in real-time to find exits can lead to dead-ends if you're not on the right node or "component". I'm sure this was solvable, but I often found there was yet another edge-case every time I thought it was fixed. Side note: a very hard lesson learned in developing an app with map data - DO NOT USE HEURISTICS - YOU MUST FIX THE DATA.
v4 - Sequences
This should have been REALLY OBVIOUS early on. The graph is not going to change dynamically over time at a rate that would warrant traversing it in real-time while folks are driving. Just pre-compute the sequence of exits and create canonicalized exit & exit sequence data - AKA a linked list. This is so unbelievably obvious upon reflection - but I had a ton of fun building ridiculous graph traversing logic.
Why it didn't work
Actually - the sequence data is great, and it's what powers Pike today. However, there was a separate problem: the POIs it was recommending sometimes didn't make sense.
Remember earlier when I said "find the upcoming exits and do a radial search for POIs". Well - imagine how well that worked for exits that don't actually exit the interstate, but instead take you onto another interstate? YOU CAN'T EXIT!
v5 - Driving time search
This was the magnum opus of this project. Pumping all of the data from OSM into Open Source Routing Machine (OSRM) and pre-computing the driving time from every interstate exit to every restaurant, gas station, EV charger, rest area, and hotel across all of the continental United States. This required an instance on AWS with over 200 GB of memory that cost $1k+ a month (thankfully I only needed for a few hours) in order to compute. What a magnificent open-source project. Both OSM and OSRM. Incredibly simple to do given the overarching complexity. With this tool I pre-computed both the driving distance and driving time for every exit POI combination. That is what enables Pike to be so accurate with the POIs it recommends. If you can't get there in 5 minutes, it's not going to recommend it. I plan on making the timing configurable in the future.
Closing thoughts
So there you have it. Pike was a wonderful lesson on how OSM data works and the tooling ecosystem that surrounds it. I learned a valuable lesson of ditching heuristics for map problems - never again. I also, for the first time, wielded the power of a super chonky machine in the cloud. I've always wanted to just solve problems "locally" but in this case I simply didn't have the means. Using Claude to help guide me on how to spin up the instance and prepare it for the compute was so dang easy - I couldn't believe it. I couldn't believe I had spent HOURs running out of memory on my local machines before finally begging Claude for mercy.
If you think this app could be useful for you in the future, give it a shot! I would love any feedback. Safe travels.
More Screenshots
