NightRoute - Build for a Friend

hehe — Mon, 05 Oct 2026 06:01:02 +0000

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:

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.

DEV Community: hehe