This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend
NightRoute: A Route Planner That Cares About How You Get Home
Hacktoberfest Weekend Challenge: Build for a Friend
A friend sometimes has to travel alone in the evening.
That got us thinking about a pretty simple question:
When you're going home at night, do you always want the fastest route?
Maybe not.
Sometimes you might be completely fine taking an extra 5 minutes if the other route has more shops, public places, transport, pharmacies, or other things around it.
Most navigation apps are really good at answering:
What's the fastest way to get there?
We wanted to explore a slightly different question:
What do the different routes actually look like?
So we built NightRoute.
What does NightRoute do?
You enter a starting point and destination.
NightRoute gets multiple route options and looks at what's around each route.
Things like:
- Shops and businesses
- Restaurants and cafés
- Bus stops and public transport
- Pharmacies
- Hospitals
- Police stations
- Opening hours, where available
- Route characteristics
- Available traffic and activity indicators It then combines these signals into a Route Context Score. And this part was really important to us: NightRoute doesn't say that a route is safe. The available data simply isn't enough to make a claim like that. Instead, it gives you more context about the routes so you can decide for yourself.
How to try it
Live Demo: https://architect-cholesterol-dis-beauty.trycloudflare.com/
GitHub: https://github.com/aashitas987-spec/NightRoute---Build-for-a-Friend
How We Built It
1. Get the routes
We use the Google Routes API to get route alternatives and their geometry.
2. Look around the routes
We sample the route geometry and use OpenStreetMap and Overpass to find things around each route.
For example, if one route passes through an area with several shops, restaurants and bus stops while another has very little mapped activity, NightRoute can capture that difference.
3. Calculate the score
The score is not generated by AI.
It's calculated by the application using weighted signals:
| Signal | Weight |
|---|---|
| Traffic / travel conditions | 25 |
| Activity | 30 |
| Safety services | 20 |
| Bus stops / public transport | 10 |
| Directness | 15 |
| Total | 100 |
| So if the same data goes into the system twice, the result is reproducible. |
4. AI explains the result
This was one of the most interesting parts of the project for us.
We use Gemma 3 4B with Ollama to explain the result.
The model gets the structured information from the scoring system and turns it into something easier to understand.
The architecture is basically:
Data → Scoring → Explanation
The AI isn't responsible for inventing the score or deciding whether a route is safe.
We wanted it to explain the information rather than make the decision.
A Simple Example
Imagine NightRoute finds two routes.
Route A
25 minutes
- Shorter
- More direct
- Fewer businesses along parts of the route
- Less public transport nearby
Route B
30 minutes
- Slightly longer
- More listed businesses
- More public transport
- More nearby services A traditional navigation system might naturally favour the faster route. NightRoute shows the trade-off. Maybe you take Route A because you don't care about the extra context. Maybe you take Route B because you're travelling alone late at night and would rather have more activity around you. That's your choice. NightRoute just tries to make that choice a little more informed.
Why We Wanted to Build This
This project came from a very normal situation.
Someone you care about texts:
I'm leaving now.
And your brain immediately goes:
Okay... which route are you taking?
We didn't want to build another emergency button or another system that constantly tracks someone.
We wanted something much simpler.
Just give us more information before we leave.
That's basically where NightRoute started.
The Part We Were Careful About
While building this, we kept running into the same question:
Can we actually call a route safe?
The answer is no.
If OpenStreetMap has a restaurant listed, that doesn't mean it's definitely open.
If there are 10 shops nearby, that doesn't mean there will definitely be people around.
A nearby police station doesn't automatically make a road safe.
And a score of 85/100 definitely doesn't mean 85% safe.
So we decided to call it a Route Context Score instead.
The score is basically saying:
Here are some things we found around this route.
Not that nothing bad will happen there.
That distinction matters a lot for a project like this.
Why Use an Open Model?
We also wanted to experiment with using an open and local model instead of sending everything to a closed AI API.
That's where Gemma and Ollama came in.
During development, the explanation layer can run locally.
We liked that architecture because the application doesn't need AI to do everything.
The maps provide the data.
The scoring system does the calculations.
The LLM explains the result.
Each part has a clear job.
Tech Stack
Frontend
- React
- TypeScript
- Vite
- Tailwind CSS
- React Leaflet
Backend
- Python
- FastAPI
Maps and Data
- Google Routes API
- OpenStreetMap
- Overpass API
- Nominatim
AI
- Gemma 3 4B
- Ollama
Other
- Caching
- Rate limiting
- Route geometry processing
- Deterministic scoring
What We Learned
Probably the biggest thing we learned from this project is that AI doesn't always need to be the thing making the decision.
When we started thinking about the project, it would have been very easy to say:
Let's use AI to predict whether a route is dangerous.
But that immediately raises some questions.
Based on what?
How do we verify it?
What happens when the model is wrong?
Instead, we ended up with something we liked more:
Give the system real data, calculate something reproducible, and let AI explain it.
That made us think differently about AI projects in general.
Sometimes the interesting part isn't making the model do more.
It's figuring out where the model actually belongs.
What's Next?
This is still a hackathon MVP, so there is a lot we'd like to improve.
Some things on our list:
- Better route segmentation
- Better activity indicators
- More detailed opening-hour handling
- Better confidence estimates when map data is limited
- More useful route explanations
- More open geographic data
- Better evaluation of the scoring system And probably the biggest one: Figure out which signals actually make NightRoute more useful without giving people a false sense of security.
Team
NightRoute was built by:
AASHITA SINGH
BHOOMI VAITY
PURVA SHINDE
One Last Thing
NightRoute started with a pretty simple thought.
When someone you care about says they're heading home, sometimes you don't need another alarm.
You just want to know a little more about the road they're taking.
That's what we wanted NightRoute to do.
Because getting home isn't always just about getting there as fast as possible.
Top comments (0)