Inspiration
Edinburgh is one of the most beautiful cities in the world to walk through. On my way between my accommodation and university, I always wanted to take a different route and find streets, closes and viewpoints I hadn't seen yet. The problem is that in the morning, exploring means getting lost and being late for class. More generally, I wanted to go on walks and runs that let me explore the city too, without spending ages planning a route or checking the map every five minutes. So I wanted something that answers one question: "I've got this much time, where should I go?"
What it does
You pick how much time you have (5 minutes to 8 hours), where you're starting, and whether to loop back, head somewhere specific, or finish anywhere. Wally finds interesting stops nearby and builds routes that fit your time using real walking times.
Mood tags (Scenic, Green, Historic, Hidden gems) that you can combine A walk/run toggle: running plans longer routes for the same time It remembers where you've been and steers you somewhere new Rate and favourite routes, and bring your favourites back with one tag Loops come home a different way from the one they went out If a destination can't be reached in time, the route is shown in red with how much longer it takes
How we built it
The web app is Next.js, TypeScript and Tailwind, using Google Maps, Places API and Routes API. I wrote the route planner myself. It finds nearby places, scores combinations of stops (scenery, novelty, your moods, your history), checks the best ones against real walking times, and ranks them by how well they fill your time. There's a SwiftUI iOS app with a Swift port of the same logic, and around 285 automated tests. I used Claude Code as a pair programmer.
Challenges we ran into
Making routes actually fit the time: straight-line estimates are always wrong, so Wally learns from real walking times as it searches. Keeping API costs low: each search makes only a limited number of requests. Loops that weren't loops: some loops came back along the same road they went out on, so I had to detect that and reroute the way home. Long walks failing: the place search had a fixed size limit, so walks over about 90 minutes couldn't find stops far enough away. Keeping two apps in sync: the web and iOS apps have to plan routes the same way. It works: I can ask for a 30-minute loop from my flat and end up somewhere new. Routes fit your time using real walking data. It gets better the more you use it. It's honest when somewhere is too far away.
Accomplishments that we're proud of
It works: I can ask for a 30-minute loop from my flat and end up somewhere new. Routes fit your time using real walking data. It gets better the more you use it. It's honest when somewhere is too far away. There's a polished web app and a native iOS app*.
What we learned
Real-world routing is messy, and "close enough" isn't good enough when you have a 9am lecture. Balancing several scoring factors is harder than it looks. Small details, like red warnings or loops that don't retrace their steps, are what make people trust the app.
What's next for Wally
Use everyone's ratings to recommend better routes Real local events instead of the current sample ones Learn your actual running pace Sync history across devices A commute mode: "get me to uni by 9:00, but make it interesting" More cities
Built With
- css
- eslint
- google-maps
- google-places
- google-routes-api
- ios
- next.js
- node.js
- react
- swift
- swiftui
- tailwindcss
- typescript
- vitest
- xcode
Log in or sign up for Devpost to join the conversation.